Some Tom Dick and Harry to VCs: I have a proposal for you.
VCs: what is it
Tom Dick & Harry: AI
VCs: get the ** out of here, we already burnt enough money and will never see it back
Tom Dick & Harry: hear me out this is different
VCs: ok you have 5 minutes to explain me your product
Tom Dick & Harry: I dont have one
VCs: get the ** out of here
Tom Dick & Harry: hear me out
VCs: ok, you have 30 seconds to impress us.
Tom Dick & Harry: I just quit Microslop and still have high level contacts there
VCs: Hot damn!!! you are our lottery ticket to recoup all the money we have lost in other ventures. This is going to be a race against time, before your contacts go stale. Here's 60M for you, wine and dine your friends with it. On your way out you will find some AI generated product names and some vague product descriptions. Pick one and slap it on some website and announce our deal. Now get the ** out of here.
> Checkpoints are a new primitive that automatically captures agent context as first-class, versioned data in Git. When you commit code generated by an agent, Checkpoints capture the full session alongside the commit: the transcript, prompts, files touched, token usage, tool calls and more.
This thread is extremely negative - if you can't see the value in this, I don't know what to tell you.
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.
There’s a difference between “this concept has value” and “a company can capture that value”.
I do see value in this, but like you I think it’s too trivial to implement to capture the value unless they can get some kind of lead on a model that can consume these artifacts more effectively. It feels like something Anthropic will have in Claude Code in a month.
There's no way this company is just a few git and claude hooks with a CLI. They're definitely working on a SASS - something else that isn't open source that this primitive is the basis of. Like a GitHub for agent code
> 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?
You are correct, that isn't the moat. Writing the software is the easy part
git didn't succeed based on the mental model. It got a foot in the door with better tooling and developer experience then blew the door open when GitHub found a way to productize it.
I have never seen any thread that unanimously asserts this. Even if they do, having HN/reddit asserting something as evidence is wrong way to look at things.
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.
>what's the value of paying someone for a product like this vs just building it myself?
Same thing it’s always been. Convenience. Including maintenance costs.
AI tools have lowered the bar significantly on some things, so SaaS offerings will need to be better, but I don’t want to reinvent every wheel. I want to build the thing I want to build, not the things to build that.
Just like I go to restaurants instead of making every meal myself.
Right, but paying for food at a restaurant doesn't get me any closer to owning a restaurant. If promises are delivered on for these agentic coding platforms (which I do believe in), it seems the most reasonable path forward is to use those platforms to build your own platform.
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.
My mental model is that LLMs are obedient but lazy. The laziness shows in the output matching the letter of the prompt but with as high "code entropy" as possible.
What I mean by "code entropy" is, for example, copy-paste-tweak (high entropy) is always easier (on the short term) for LLMs (and humans) to output than defining a function to hold concepts common across the pastes with the "tweak" represented by function arguments.
LLMs will produce high entropy output unless constrained to produce lower entropy ("better") code.
Until/unless LLMs are trained to actually apply craft learned by experienced humans, we must be explicit in our prompts.
For example, I get good results from say Claude Sonnnet when my instruction include:
- Statements of specific file, class, function names to use.
- Explicit design patterns to apply. ("loop over the outer product of lists of choices for each category")
- Implementation hints ("use itertools.product() to iterate over the combinations")
- And, "ask questions if you are uncertain" helps trigger an iteration to quickly clarify something instead of fixing the resulting code.
This specificity makes prompting a lot more work but it pays off. I only go this far when I care about the resulting code. And, I still often "retouch" as you also describe.
OTOH, when I'm vibing I'll just give end goals and let the slop flow.
Many, many years ago, when ~persia came ashore~ dropbox was announced on HN [0] The top comment was quick to point out "For a Linux user, you can already build such a system yourself quite trivially
I mean a dev tool that's seemingly failing to resonate with developers as to why they would pay for this is a pretty good way to tell if it's going to fall in the 1%.
The Dropbox take was wrong because they didn't understand the market for the product. This time the people commenting are the target audience. You even get the secondary way this product will lose even if turns out to be a good idea, existing git forges won't want to lose users and so will standardize and support attaching metadata to commits.
> This time the people commenting are the target audience.
Nah. People post about k8s on here all the time, but that doesn't mean I'm the target audience. Just because _someone_ on HN has a bad take doesn't mean they're the person who needs this. Nor does it mean they even understand it.
predicting that a startup will fail is.. well, you got a ton of probability on your side there. so it isn't a particularly impressive thing to be right about.
Unimpressive doesn't mean incorrect, sometimes it's good to take the side of the most probable. And yet at the same time I am reminded of this quote:
> The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw
I'm not disagreeing, just soliciting. Does anyone have examples of products that failed in the early stages because their implementation was too trivial?
There are a number of ways. Obviously Dropbox would be one case of "early and didn't fail" that could have been "early and failed", and we would have heard about it.
People keep saying that, but it's hardly the same thing. We're talking about developer workflow here. It's like someone coming up with Brancher. It's a git branch manager. Use `brancher foo` to replace `git checkout -b foo`. "Remember that comment about rsync and dropbox? Brancher is to git, what dropbox is to rsync"
How is LangChain doing? How about OpenAI's Swarm or their Agent SDK or whatever they called it? AWS' agent-orchestrator? The crap ton of Agent Frameworks that came out 8-12 months ago? Anyone using any of these things today? Some poor souls built stuff on it, and the smart ones moved away, and some are stuck figuring out how to do complex sub-agent orchestration and handoffs when all you need apparently is a bunch of markdown files.
Just saw a Discord-weekend take on reddit! Haha. Guy was saying he could create it in a day and then self-host it on his servers so that he doesn't have to put Nitro ads on top of it
It's a common trope. (Some) artists will often convey the same message; art should be judged on how hard it was to create. Hence why some artist despise abstract art or anything "simplistic".
We forget that human consumption doesn't increase with manufacturing complexity (it can be correlated, but not cause and effect). At the end of day, it's about human connection, which is dependent on emotion, usefulness, and availability.
I mean, I CAN see the value in pushing the context summary to git. We already have git blame to answer "who", but there is no git interrogate to answer the "why". This is clearly an attempt to make that a verb git can keep track of. It's a valuable idea.
I also seen examples of it before. I've got opencode running right now and it has a share session feature. That whole idea is just a spinoff on the concept of the same parent that led to this one.
It's the valuation that is wild to me (I think the idea itself has merit). But these are the new economics. I can only say "that's wild" enough before it is in fact no longer wild.
These aren't new economics, it's just VC funds trying to boost their holdings by saying it's worth X because they said so. Frankly the FTC should make it illegal.
Of course it's how it works, how else do you justify a company that is making negative profit into some how being worth $300M? Like that's just the game, IDK why people accept it. It's not democratic and all it does it prime the population for fraud and abuse.
I don't need to "play the game" to realize private valuations are just marketing fluff not based in reality. It's literally "the greater fool" theory in action. When the incentives are to just lie and not put out something with some actual scrutiny like a 409A, it's quite clear what game is being played.
But yes, I would totally love to invest in startups with people's pension funds. It seems like the perfect scam where the only losers are the public that allows such actions.
Almost all of the world's most valuable companies were once VC investments that I'm sure you would have dismissed as just greater fool nonsense.
But more to the point, I was talking about how you apparently think VCs just make up super high valuations of the companies they invest in to justify those investments? Are you not aware that VC is a competitive market?
That is where I’m shocked being in a position of raising for a startup myself, what was in their pitch deck/data room that convinced them of this valuation? Or is it due to the founders reputation and not the substance?
That's not impressive. That's an incredible amount concentrated in the hands of a few looking for a place to live. It has to end up somewhere. Some of it goes everywhere.
I think discord became popular in the first place because it was so much better than the alternatives, at least for the gaming/ hanging out with friends use case.
Discord was initially competing with a bunch of self hosted stuff, vent/ mumble etc with higher barrier to entry and less features and Skype which was terrible.
Discord really became big because it had 0 obstacle onboarding. In an age of Skype, Ventrillo, Teamspeak and Mumble, all "installation" software with "server addresses" and "setup your user config", Discord shows up, says "press this link", and done, you're ready to go. Install link? No, it's in the browser. Account? No, you literally got a temp account made for you. You just talked. Yes, with a button in the corner that says "Claim this account" which just wants an email and a name, but point is, you didn't even have to do that much. This is why the comparison to it is IRC despite the two being so far apart, IRC was the only other chat software with this small of a barrier to entry.
Everything else about the featureset was copy pasted from Slack. No one cares about that part.
We have had this for ages now.... I just don't have access to the sort of people willing to pass me 60m for that. I never thought it to be worth anything really ; it was a trivial to implement afterthought.
Well a famous name is attached, could be the start of the product that replaces github, building github2 would give oppertunity to fix mistakes that are too entrenched to change at github, and who better to try? I'm uncharacteristically optimistic on this one, I'd give it a try!
I love this one so much! The arbitrary decision to cherry-pick critique a particular product to this degree, when it’s something that could be said about 99% of the stuff SV churns out, including in all likelihood anything you’ve ever worked on.
Good thing the comment you're replying to does not lionise 99% of the stuff SV churns out, including in all likelihood anything they've ever worked on. I guess we should just not critique anything out of SV because it's all shit?
The most active HNers are just extremely negative on AI. I understand the impulse (you spend years honing your craft, and then something comes along and automates major portions of it) but it's driven by emotion and ego-defense and those engaged in it simply don't recognize what's motivating them. Their ego-defense is actually self-fulfilling, because they don't even try to properly learn how to leverage LLMs for coding so they give it a huge task they want it to fail on, don't properly break it into tasks, and then say "i told you it sucks" when it fails to one shot it.
Even this response shows why the most active ones are outwardly negative on AI.
I use AI a ton, but there are just way too many grifters right now, and their favorite refrain is to dismiss any amount of negativity with "oh you're just mad/scared/jealous/etc. it replaces you".
But people who actually build things don't talk like that, grifters do. You ask them what they've built before and after the current LLM takeoff and it's crickets or slop. Like the Inglourious Basterds fingers meme.
There's no way that someone complaining about coding agents not being there yet, can't simultaneously be someone who'd look forward to a day they could just will things into existence because it's not actually about what AI might build for them: it's about "line will go up and I've attached myself to the line like a barnacle, so I must proselytize everyone into joining me in pushing the line ever higher up"
These people have no understanding of what's happening, but they invent one completely divorced from any reality other than the reality them and their ilk have projected into thin air via clout.
It looks like mental illness and hoarding Mac Minis and it's distasteful to people who know better, especially since their nonsense is so overwhelmingly loud and noisy and starts to drown out any actual signal.
> if you can't see the value in this, I don't know what to tell you.
You could perhaps start by telling what value you see in this? And what this company does that someone can't easily do themselves while committing to GH?
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.
But that's not what is in the whole context. The whole context contains a lot of noise and false "thoughts".
What the AI needs to do is to document the software project in an efficient manner without duplication. That's not what this tool is doing.
I question the value in storing all the crap in git.
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.
How does this differ from what Github Copilot does when writing its .github/copilot-instructions.md? That doesn't keep the transcript or prompts, but it does keep quite a bit of the context and a declarative state of the decisions/design considerations made so another AI bot can pickup and have enough context to understand the rationale. I'm also not really convinced that any AI agent wouldn't still parse the code to understand more about the context vs. just using the checkpoint.
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 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.
Sure, but long term business success aside, I’m sure most of the folks working at this company would die for a fraction of the adoption curve docker had.
I think this is neat; in fact, I orchestrated my AI agents to do something similar (keep a log of files touched and why). And I have agents refer to the work log as well when they are unclear on why something exists.
It's not 1:1 with checkpoints, but I find such things to be useful.
I've used it for a couple of hours. A few observations:
- It's nice to see conversation context alongside the change itself.
- I wasn't able to see Claude Code utilise past commit context in understanding code.
- It's a tad unclear (and possible unreliable) in what is called 'checkpointing'.
- It mucked up my commit messages by replacing the first line with a sort of AI request title or similar.
Sadly, because of the last point (we use semantic release and git-cz) I've had to uninstall it.
This sounds like you're using the auto-commit strategy instead of the default manual-commit strategy. manual-commit does not automatically commit. It just adds a trailer to the git commit message to link the checkpoint to the commit.
Do you mean the value in this specific tool, or in the concept? You don't need a dedicated tool to store agent session transcripts and link them to commits. This can be accomplished by a 10-line bash script.
It's in active development in my free time. I've built various agent orchestration systems over the years for different reasons, ever since the GPT-3 API. I can tell you utility has continually risen, the models are just getting better, and late 2025 was an inflection point, which is why we're seeing all of these orchestration solutions pop up now.
I still have kinks to work out in mine but it's already usable for building software. Once I get to v1 I think it will provide enough value to be useful for me in particular. I don't have enough data to speak about months on yet, but if I think the experiment is a success then I will do a Show HN or something.
The gist is you can clone a repo or start a project from scratch, each engineering agent gets a worktree, you work with the manager agent and it dispatches and manages other agents. there are playbooks which agents contextually turn into specific tasks, each of which is tracked much like CI/CD. You can see all the tool calls, and all of the communication between both agents and humans.
The application model is ticket-based. Everything revolves around the all-holy ticket. It's like a prompt, but it becomes a foundation for tying together every bit of work related to the process of developing the feature. So you can see the progress of the ticket through the organization kanban style, or watch from a dashboard, or look at specific tickets.
There are multiple review steps where human review and intervention are required. Agents are able to escalate to humans whenever they think they need to. There is a permission system, where agents have to seek permissions from other agents or humans in a chain of command in order to do certain tasks. Everything is audited and memoized, allowing for extreme accountability and process refinement stages.
Additionally, every agent "belongs" to either another agent or a human, so there is always a human somewhere in the chain of command who is responsible and accountable for the actions of his agent team. This team includes the manager agent, engineering agents, test agents, QA agents, etc, each loaded with different context, motivations and tools to keep them on track and attempt to minimize the common failure modes I experience while working closely with these tools all day.
> This thread is extremely negative - if you can't see the value in this, I don't know what to tell you.
This sounds a lot like that line from Microsoft's AI CEO "not understanding the negativity towards AI". And Satya instructing us to not use the term "slop" any more.
Yes we don't see value in taking a git primitive like "commit" and renaming it to "checkpoint". I wonder whether the branches going to be renamed to something like "parallel history" :)
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.
>. This thread is extremely negative - if you can't see the value in this, I don't know what to tell you.
It's almost a meme: whenever a commercial product is criticized on HN, a prominent thread is started with a classic tone-policing "why are you guys so negative".
(Well, we explained why: their moat is trivial to replicate.)
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.
Please don't use quotation marks to make it look like you're quoting someone when you aren't. That's an internet snark trope and we're trying to avoid those on HN.
Look it’s obvious at this point to anyone who is actually using the tools.
We can articulate it but why should we bother when it’s so obvious.
We are at an inflection point where discussion about this, even on HN, is useless until the people in the conversation are on a similar level again. Until then we have a very large gap in a bimodal distribution, and it’s fruitless to talk to the other population.
I will never use this platform. i didn't even click into it. pathetically, i did click to view comments
But I think commenting on someone's bio is the kinda harshness you only do in the moment. the kinda thing I'd approach differently in hindsight (one that isn't an attempt to be cruel)
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…
> Spec-driven development is becoming the primary driver of code generation.
This sounds like my current "phase" of AI coding. I have had so many project ideas for years that I can just spec out, everything I've thought about, all the little ideas and details, things I only had time to think about, never implement. I then feed it to Claude, and watch it meet my every specification, I can then test it, note any bugs, recompile and re-test. I can review the code, as you would a Junior you're mentoring, and have it rewrite it in a specific pattern.
Funnily enough, I love Beads, but did not like that it uses git hooks for the DB, and I can't tie tickets back to ticketing systems, so I've been building my own alternative, mine just syncs to and from github issues. I think this is probably overkill for whats been a solved thing: ticketing systems.
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".
That's hilarious, I called it gates too for my reimplementation of Beads. Still working on it a bit, but this is the one I built out a month back, got it into git a week ago.
For me a gate is: a dependency that must pass before a task is closed. It could be human verification, unit testing, or even "can I curl this?" "can I build this?" and gates can be re-used, but every task MUST have one gate.
My issue with git hooks integration at that level is and I know this sounds crazy, but not everyone is using git. I run into legacy projects, or maybe its still greenfield as heck, and all you have is a POC zip file your manager emailed you for whatever awful reason. I like my tooling to be agnostic to models and external tooling so it can easily integrate everywhere.
Yours sounds pretty awesome for what its worth, just not for me, wish you the best of luck.
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.
I’m testing this as well, but I’ve no idea people are getting good results out of Claude. What a waste of money… it’s incredible. It will get stuck on everything: basic string substitution, trying to install Python dependencies in a Node project, finding usages of something it’s trying to edit, and on and on.
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.
I started off with the original beads and it was definitely a nightmare. However I would recommend using https://github.com/Dicklesworthstone/beads_rust - it's a much simpler implementation of the same concept, without all the random extra stuff thrown on to support Gas Town.
> Checkpoints run as a Git-aware CLI. On every commit generated by an agent, it writes a structured checkpoint object and associates it with the commit SHA. The code stays exactly the same, we just add context as first-class metadata. When you push your commit, Checkpoints also pushes this metadata to a separate branch (entire/checkpoints/v1), giving you a complete, append-only audit log inside your repository. As a result, every change can now be traced back not only to a diff, but to the reasoning that produced it.
The context for every single turn could in theory be nearly 1MB. Since this context is being stored in the repo and constantly changing, after a thousand turns, won't it make just doing a "git checkout" start to be really heavy?
For example, codex-cli stores every single context for a given session in a jsonl file (in .codex). I've easily got that file to hit 4 GB in size, just working for a few days; amusingly, codex-cli would then take many GB of RAM at startup. I ended up writing a script that trims the jsonl history automatically periodically. The latest codex-cli has an optional sqlite store for context state.
My guess is that by "context", Checkpoints doesn't actually mean the contents of the context window, but just distilled reasoning traces, which are more manageable... but still can be pretty large.
In simpler terms - they create an MCP server, essentially an API that the coding agent can call, that can fill in context about previous decisions done by the coding agent earlier in development. Agent equivalent of asking someone who's been working there longer "why is this this way".
This means that the agent will can have context of previous decisions, something that they currently struggle with as they are always starting from a blank slate.
> 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.
It's sad to see that ex-GitHub CEO didn't make enough money to just kick-start his company, but needs external money which will later on dictate how the company works or will sell users and the product for the next exit..
He kept 80%. The other 20% is owned by 8 different VCs. Seems like he's still in control. There's value in using other people's money instead of your own because it might make him less emotionally risk-averse in how he manages it.
Most of the time it's not about the money VCs send into it but the credibility that this brings. It looks a lot more mature when your idea is backed by a distribution of wealthy people.
The point is more - it's primary goal is not to enable developers to do more and better, it's primary goal is to _maximize shareholder value_. Important thing to keep in mind.
Exactly ... tired by all the marketing hyperbole talk. Just show what your product does in a simple example / showcase. If it's good, people will like it. You can save yourself a lot of text copy and user time that way.
CEOs have many audiences; great CEOs communicate capably with each.
FWIW it's not entirely clear to me who Entire's long-term customer is, but the (interesting!) CLI that shipped today is very much for developers who are busy building with agents.
The problem is that when it comes to (commercial) developer tools and services, everyone can/wants to be everything, so why let a simple statement or a showcase limit you? "Hey, we are a container scanning service... But we can also be a container registry too, a CI, a KeyValue store, an agent sandbox provider, git hosting? We can do quick dev deployments/preview too. Want a private npm registry? Automated pull request reviews? Code Signing service? We are working on a new text editor btw"
I feel like these types of pages are less geared towards actual users of the product and more towards the investors who love the vague and flowery language. We're no longer in a world where the path to profitability was the objective goal anyway, it makes sense to me that the marketing of software is becoming decreasingly detached from reality..
It's almost like an extension of the "if you're not paying for the product, you are the product" idea. If you're assessing a tool like this and the marketing isn't even trying to communicate to you, the user, what the product does, aren't you also kind of "the product" in this case too?
The domain expired a few days ago and was purchased by someone else and then changed. There's a recreation of the original here https://html5zombo.com/
Seems they install a Git hook or something that executes on commit and saves your chatbot logs associated with the commit hash. This is expected to somehow improve on the issue that people are synthesising much more code than they could read and understand, and make it easier to pass along a bigger context next time you query your chatbots, supposedly to stop them from repeating "mistakes" that have already wasted your time.
What it does? Imagine a multi line commit message.
Yes yes a Dropbox comment. But the problem here is 1 million people are doing the same thing. For this to be worth 60M seed I suspect they need to do something more than you can achieve by messing around locally."
"Claude build me a script in bash to implement a Ralph loop with a KV store tied to my git commits for agent memory."
This feels interesting because the real problem with AI generated code isn't that it is of better or worse quality than code written by a human, it's that we humans need to audit both types of code. And this platform feels like it addresses this in a novel and traditional way. I like it.
Checkpoints are not granular enough. You have to grab a work summary before the context window closes, not when you decide to commit. I have thousands of work summaries from one project alone. I use them to traverse sessions.
interesting. Do you have an example of what exactly it outputs and how you store that? how do you use the outputs? As a pointer to a new agent with fresh context to get them up to speed?
Note I archive these to a different non-repo folder regularly. It's fun to tell Claude to go through them like a RAG implementation and note the progress of my development over time, which I update semi-regularly at: https://david.cornelson.net/sharpee-status-20260109.html
Yes. None of this early stuff should be monetized and that Entire business model is all about monetizing something that doesn't need it.
I have hooks in Claude to auto-generate the work summary and read the last work summary on start. Now if I could only get Claude to quit/restart on its own or have it thoroughly flush its resources (even Anthropic says restarting is better), we'd be getting somewhere. I do wish there were automatic hooks that fire all the time (like a heart monitor) where I could query "if context is below 15%" do this: stop all work, write work summary, commit and push all changes, release all resources, read last work summary, continue the work.
Ignoring the VC economics and awful name, I won’t be as pessimistic as everyone. I see the vision.
That said, nobody knows what the AI future looks like. Entire’s entire thesis is a solution for something we don’t even know we need. It’s a massive bet and uphill battle. Traditionally, dev tool success stories come from grassroots projects of developers solving their own problems and not massive VC funded efforts that tell you what you need to do.
My pessimism is mostly rooted in the VC economics of it all. The vision is great, but its a busy space and there's no actual product or business. They basically wrote the guy a check to build the spaceship in space.
I actually feel like the LLM-driven AI future is relatively forseeable. It's only if we get a new, cooler architecture that we'll see a fundamental change to what we've kind of known for a while now
Actually interesting, but how's that different from just putting your learning / decision context into the normal commit text (body) ? An LLM can search that too, and doesn't require a new cli tool.
EDIT: Or just keep a proper (technical) changelog.txt file in the repo. A lot of the "agentic/LLM engineering frameworks" boil down to best approaches and proper standards the industry should have been following decades ago.
After I have an ai dona task, I ask the next one to look at that plan and git diff and so ble check validate
I don't see the need for a full platform that is separate from where my code already lives. If I'm migrating away, it's to something like tangled, not another VC funded company
This is a good idea but I feel like you could get something similar by just adding an instruction for the agent to summarize the context for the commit into a .context/commit/<sha> file as a git hook.
Exactly. I don't want to wade through a whole session log just to get to reasoning, and more importantly, I don't want to taint my current agent context with a bunch of old context.
Context management is still an important human skill in working with an agent, and this makes it harder.
Agents can save their reasoning into markdown files, and commit those files to Git. Are "Checkpoints" just a marketing term for that, or there's more to it?
Claude Code already does this, you can access it with /resume, /rewind and /fork. I'd imagine building a version that saves in the repo instead of in the home folder would take very minimal effort.
I think the moat depends on how long it takes for an agent to ingest the entire commit history and product documentation into context on the fly. At the rate models are improving, seeing the reasoning chain of an outdated model that led to a commit that warrants post-hoc review (likely becuase of a bug) would mainly be useful for root cause analysis more than for insight into what to do next... but chances are the newer model would have been able to infer it from local context anyway.
It also creates a challenge with respect with the embedding model chosen and how future proof it turns out to be.
I landed on a similar vision last year. The more I thought about it, the moat felt fragile. GitHub or GitLab could build the same capabilities and become a natural extension of what teams already use. That said, it addresses a real problem, and the SDLC needs to evolve.
The product isn't the software, it's your data. The VC's didn't give Dohmke $60m to build a new frontend for Git/ GitHub... They're going to capture your conversations and code with AI (The outcomes) and use that to train better models which they'll rent back at you.
Hmm the whole point of checkpoints seems to be to reduce token waste by saving repeat thinking work. But wouldn't trying to pull N checkpoints into context of the N+1 task be MUCH more expensive? It's at odds with the current practice of clearing context regularly to save on input tokens. Even subagents (which I think are the real superpower that Claude Code has over Gemini CLI for now) by their nature get spawned with fresh near-empty context.
Token costs aside, arguably fresh context is also better at problem solving. When it was just me coding by hand, I didn't save all my intermediate thinking work anywhere: instead thinking afresh when a similar problem came up later helped in coming up with better solutions. I did occasionally save my thinking in design docs, but the equivalent to that is CLAUDE.md and similar human-reviewed markdown saved at explicit -umm- checkpoints.
Yes I also don't see how having persistent context would help. For one, I don't want to read the slop the AI produced while it wrote the code. It doesn't have intent or thinking, it's a completion machine. The code is the artifact that matters, not the thousands of lines of "Your absolutely right --- I was wrong to ..."
Also, sometimes it gets something very wrong. I don't want to then poison every subsequent sessions with the wrong thing it learned. This has been a major issue for me at $WORK with AGENTS.md files that my colleagues write: they make my agent coding much worse so I need to manually delete them often.
Is this the product? I don't want to jump on the detractor wagon, but I read the post and watched the video, and all I gathered is that it dumps the context into the commit. I already do this.
I guess if I had to do it, I'd reject pushes without the requisite commit to entire/checkpoints/v1. I think their storage strategy is a bit clunky for that, but it can be done. I might look to do something more like the way jujutsu colocates its metadata. I don't think this particular implementation detail makes too much of a difference, though. I got along just fine in a regulated environment by setting a policy and enforcing it before git existed. Ideally, we'd do things for a good reason, and if you can't get along in that world, then it's probably not the right job for you. Sometimes you've got to get the change controls in order before we can mainline your contributions because we have to sustain audits. I don't think this is about forcing people to do something that they otherwise wouldn't do if you told them that it's a requirement of the job.
100%. Day one is to ship the basic capability, which many of us have already vibe-coded... Day two is all the enterprise stuff to make big companies trust AI coding more. That could unlock a lot of revenue. This isn't random at all.
Git is totally fine keeping a few extra text files. These are ephemeral anyway. The working sessions just get squashed down and eliminated by the time I've got something worth saving anyway. At that point, I might keep a overview file around describing what the change does and how it was implemented.
(I will give the agent boom a bit of credit: I write a lot more documentation now, because it's essentially instruction and initial instruction to anything else that works on it. That's a total inversion, and I think it's good.)
The bigger problem is, like others have said, there's no one true flow. I use different agents for different things. I might summarize a lot of reasoning with a cheap model to create a design document, or use a higher reasoning model to sanity check a plan, whatever. It's a lot like programming in English. I don't want my tool to be prescriptive and imposing its technical restrictions on me.
All of that aside: it's impossible that this tool raised $60 million. The problem with this post is that it's supposed to be a hype post about changing the game "entirely" but it doesn't give us a glimpse into whatever we're supposed to by hyped about.
I have it (claude, codex) summarise what we've discussed about a design, big change, put it in an MD file and then I correct it, have it re-read it and then do the change.
Then later if it goes off piste in another session tell it to re-read the ADDs for x, y and z.
If someone could make that process less clunky, that would be great. However it's very much not just funnel every turd uttered in the prompt onto a git branch and trying a chug the lot down every session.
Very similar for me. I have a plans folder in my root where I store the plans while they're either under improvement or under implementation. Once they're done they're moved into the plans/old folder. So far it's worked great. It's a couple of manual steps extra but very helpful record.
Pretty much the same thing. I don't find it to be a burden. Regarding the product, I'm willing to believe I just don't see big picture, but without some peek at the magic, I don't know how much easier this could really be.
Huh, the checkpoint primitive is something that I've been thinking about for a while, excited to see how it's implemented in the CLI. Git-compatible structures seem to be a pretty big pull whenever they're talking about context management.
I'm not making a judgement on the product but why is everything about selling shovels? I want to see "real" software and new innovative ideas that are developed and maintained using AI and not just shovels 'advertised' on HN every week.
Show me the next blockchain or noSQL, or git!
Everything is "I took a prompt and stapled it to another prompt and added <insert existing OSS> framework".. and then. holds hand out "MONEY PLEASE!"
Feature plans generated by agents are often transient documents that fall away once the plan is executed. Ideally, that artifact would be preserved alongside the implementation.
My experience is that Cursor's reliance on VS Code's clunky panel-based UI and jack-of-all-trades harness is holding it back. Likewise, Claude Code shoe-horning a GUI into a TUI and perma-binding to a single model family is not the ideal end-state.
The VC play here? The git context CLI thing is a foundational step that lays the groundwork for a full IDE/workflow tool, I guess.
If you don't have a record of questions asked/answered and rationale for decisions taken, I've noticed it's easy for subsequent feature plans to clash. Maintaining a line of consistency across each feature plan is a good thing.
Checkpoints sounds like an interesting idea, and one I think we'll benefit from if they can make it useful.
I tried a similar(-ish) thing last year at https://github.com/imjasonh/cnotes (a Claude hook to write conversations to git notes) but ended up not getting much out of it. Making it integrated into the experience would have helped, I had a chrome extension to display it in the GitHub UI but even then just stopped using it eventually.
I like the concept, but it seems like an obvious extension of where Anthropic is building with Tasks and Memory. What’s the moat? Cross-agent compatibility?
disclosure: i run a startup that will most likely be competitive in the future.
I welcome more innovation in the code forge space but if you’re looking for an oss alternative just for tracking agent sessions with your commits you should checkout agentblame
Did you have to choose an adjective to name your product. Now it’s going to be very confusing for search engines and LLms.
“Tell me more about entire.”
“Entire what?”
“You know, that entire thing.”
Another of your competitors here. It makes me giggle that we're going after the entire developer experience while Entire is only looking at a small corner of it.
Certainly! But just to confirm, you aren't making an IDE or building a version control system to replace Git, are you? While money means you need not fear me, the scale of my vision means that I don't fear you either.
> When you push your commit, Checkpoints also pushes this metadata to a separate branch (entire/checkpoints/v1)
For Claude Code, this is literally a JSONL file in .claude/projects/[path with - instead of /]/[uuid].jsonl... You can trivially have Claude Code write a commit hook to do this for you if you find it useful.
I'm sure their vision is wider than that, but they will need to iterate fast for this not to be made obsolete before they can even release something.
FWIW, I had an agent adding archiving of the JSONL for changesets linked to the work they're doing right as I started looking at this article, as when you start automating a non-interactive agent flow it's such an obviously necessary step to be able to retrospectively improve the workflows.
I'm taking a very crude approach for now. My "improvement agent" has a few distinct stages: A goals extraction step that explores the repository, with some pointers to specific files that is consider authoritative as to the users intent, and then builds out files in docs/goals. That then feeds into a plan ideation stage that results in directories for plans in docs/plans. That directory has the plan itself, and logs of revisions etc. So for now I'm just dumping snapshots of those jsonl line files in there.
Putting it in a branch so it doesn't pollute your checked out copy may well be a good idea in the longer run. For now, I keep all the plans available, as I then have a review stage that reviews all the plans, and writes things like "the user got increasingly exasperated as the agent kept ignorning direction" :D and helps propose improvements to the tool and workflow to reduce the number of those exasperated movements...
I'm thinking of packaging it up and open-sourcing it. It's all very experimental and likely to totally change every day for now, but I find it helpful. It's built me a personal dashboard, and keeps adding stuff to it with relatively minimal direction beyond "spying" on my notes and journal at this point. At one point a plan specifically called me out for procrastinating and planned for how to "work around" that with tooling (I wish it'd succeed at that).
There's nothing really fancy here, just feedback loops that ensures the wild claims the agents sometimes will make are tested and rejected.
To the original JSONL bit, the uuid you need to look it up is also the UUID you need to call "claude --resume [uuid]", so extracting it also allows for e.g. having the verification agent (that checks if the implementation agent was truthful when ticking off the quality gates - spoiler: it very often isn't) feed its report back into the original implementation conversation if rejected, instead of having the implementation agent "start over" without the full context. I haven't tested that yet, but I'm hopeful.
Though even if you don't have it restart, you can point it to the snapshot of the previous conversation as a source of additional info, as another option.
That sounds incredibly interesting and helpful. You should pack it up and open source it. You might even get $60 million. I'd be super interested in seeing it. I love that idea about the UUID. I've been experimenting with that myself. I'd be interested in working on this with you if you wanted to open source it.
I'm sure they have a vision of something but I also think the moat is narrow here. A lot of what these companies thinks will be "special sauce" will be unnecessary because the frontier models are advancing 6 months from now, and survival at that point will come down to extremely proficient execution to manage to stay ahead.
(And most of these companies will not be good enough at that)
I don't understand how this is different from giving an agent access to github logs? The landing page is terrible at explaining what it does.I guess they are just storing context in git aswell?
So is this just a few context.md files that you tell the agent to update as you work and then push it when you are done???
I had a similar, admitted poorly thought out idea a few months back.
I wanted to more or less build Jira for agents and track the context there.
If I had to guess 60 million is just enough to build the POC out. I don't see how this can compete though, Open AI or Anthro could easily spin up a competitor internally.
You don't need to build anything. Just tell the agent to write tickets into .md files in a folder and move them to a closed foler as you go along. I've been using Claude Code with the Max plan nonstop essentially every day since last July and since then I've come to realize that the newer people are the more things they think they need to add to CC to get it work well.
Eventually you'll find a way that works for you that needs none of it, and if any piece of all the extras IS ever helpful, Anthropic adds it themselves within a month or two.
I'm thinking a customized LLM would write notes in its own hyper compressed language which would allow it to be much much more efficient.
For debugging you could translate it out to English, but if these agents can do stuff without humans in the loop, why do they need to take notes in English?
I can't imagine creating this without hundreds of millions if not billions. I think the future is specialized models
They're literally trained on natural language to output natural language. You would need to create the hyper compressed language first, convert all of your training data to that, and then train the models with that. But token efficiency per word already does vary between different languages, with Chinese being like 30%-40% more efficient than English last I heard
love the shout but git-ai is decidedly not trying to replace the SCMs. there are teams building code review tools (commercial and internal) on top of the standard and I don't think it'll be long before GitHub, GitLab and the usual suspects start supporting it since folks the community have already been hacking it into Chrome extensions - this one got play on HN last week https://news.ycombinator.com/item?id=46871473
The lack of explanation of what it is and does is a tell of what gullible audience they are seeking.
Tech marketing has become a lot like dating, no technical explanation and intellectual honesty, just word words words and unreasonable expectations.
People usually cannot be honest in their romantic affairs, and here it is the same. Nobody can state: we just want to be between you and whatever you want to accomplish, rent seeking forever!
Will they ever care to elaborate HOW things works and the rationale behind stating this provides any benefit whatsoever? Perhaps this is not intended for those type of humans that care about understanding and logic?
No, because the goal isn't to make things work. The goal is to make money by appearing to make things work. People who actually know don't tend to take ridiculous sums of money just to go tinker for a few years—they just build the damn thing and move on. The game here is perception and money—not necessarily competent engineering or legible products.
This feels a bit like when some Hubbers broke off to work on PlanetScale, except without the massively successful, proven-to-be-scalable open source tool to build off (Vitess).
If you're approaching this problem-space from the ground up, there are just so many fundamental problems to solve that it seems to me that no amount of money or quality of team can increase your likelihood of arriving at enough right answers to ensure success. Pulling off something like this vision in the current red-ocean market would require dozens of brilliant ideas and hundreds of correct bets.
For a solo developer this is pretty useless. For a team where everyone uses same coding tool this might be useful.
I am afraid however that with these tools Claude Code will just copy this in 3 months and have it as standard functionality within itself as a plugin.
Also I find it ironic that this domain is blocking all AI tools to access it, I tried to ask AI to explain what is the product and it is blocking Claude/GPT access to the website.
I shall give the benefit of a doubt given they are "building in the open". I feel my current setup already does all this though, so I struggle to see the point
It’s funny. The whole “review intent", "learning" from past mistakes, etc, is exactly what my current set up does too. For free. Using .md files said agents generate as they go.
> Checkpoints are a new primitive that automatically captures agent context as first-class, versioned data in Git. When you commit code generated by an agent, Checkpoints capture the full session alongside the commit: the transcript, prompts, files touched, token usage, tool calls and more.
Whether or not useful for agent collaboration, the data here will be more valuable than gold for doing RL training later on.
Just have a data lake with annotated agent sessions and tool blobs (you should already be keeping this stuff for evals), then give your agent the ability to query it. No need for a special platform, or SaaS.
As for SDLC, you can do some good automations if you're very opinionated, but people have diverse tastes in the way they want to work, so it becomes a market selection thing.
> Git repositories were never extended to version everything developers build with in the AI era. [... more fatalistic verbiage ...] A system that cannot be retrofitted for what's ahead.
Two paragraph later:
> Entire will be based on three key components: a git-compatible database [...]
I hacked together something similar to the concept they describe a few months ago (https://github.com/btucker/agentgit) and then ended up not actually finding it that useful and abandoning it.
I feel like the value would be in analyzing those rich traces with another agent to extract (failure) patterns and learnings, as part of a flywheel setup. As a human I would rarely if ever want to look at this -- I don't even have time to look at the final code itself!
> value would be in analyzing those rich traces with another agent to extract (failure) patterns and learnings
Claude Code supports hooks. This allows me to run an agent skill at the end of every agent execution to automatically determine if there were any lessons worth learning from the last session. If there were. new agent skills are automatically created or existing ones automatically updated as apporpriate.
Yes, I've done the same. But the issue is that the agent tends to learn too many lessons, or to overfit those lessons to that single session. I think the benefit of a tool like this is that you can give that agent a wider view when formulating recommendations.
Completely agree. But I wonder how much of that is just accomplished with well placed code comments that explain the why for future agent interactions to prevent them from misunderstanding. I have something like this in my AGENTS.md.
There is no such command, according to the docs [0]. /s
I continue to find it painfully ironic that the Claude Code team is unable to leverage their deep expertise and unlimited token budget to keep the docs even close to up-to-date automatically. Either that or they have decided accurate docs aren't important.
I would argue the largest developer tools/services acquisition in recent history was GitHub (assuming you don't count RedHat in that category). GitHub was primarily an acquisition focused on acquiring the network of developers, based on the trust and cachet GitHub had earned, with the intent to upsell (land and expand) the developers at large Enterprise companies on downstream workflows and tools.
If I were an employee looking to join Entire, or a developer evaluating the durability of Entire for my needs over the long-term, I'd ask things like —
- What's the terminal value of a DevTool in the AI era? Is it closer to a standard 10x ARR? or maybe 100x...perhaps 1000x?
- Is there value in the asset attributable to the network? If so, is it defensible? What is the likelihood protocols emerge that simply disintermediate the network moat of a AI agent memory company like Entire?
- What kind of AI data are developers willing to silo with a single vendor? What kind of controls do Enterprises expect of an AI agent memory system? Can Entire reasonably provide them to grow in the next 12-24 months?
- As a potential employee...if you join a company with a $60M seed funding and 19 employees, what is the ARR they need to achieve based on the first product in market in roughly ~12 months? $6M...$12M...20M? Is there a DevTools company that's ever done that!? What is the thesis for "this time is different"? Getting developers to pay for things is tough 'doncha know?
Only then can you ask basic technical diligence questions —
- Is Git a system that can scale to be the memory system and handle the kind of tasks that AI agents are expected handle?
- Are the infrastructure costs for these early platform decisions here reasonable over the long-term? Or do they just run out of money?
I wish them the best, and I hope employees get liquidity, and people take money off the table in a responsible way.
I did test it and use it and trashed it because there is very little value, actually none for me. These problems are easily being solved in other ways whoever has any experience with these tools. Getting $60M round for this stuff is ridiculous.
I'm interested to see if they will try to tackle the segregation of human vs AI code.
The downside of agents is that they make too much changes to review, I prefer being able to track which changes I wrote or validated from the code the AI wrote.
For people trying to understand the product (so far), it seems that entire is essentially an implementation of the idea documented by http://agent-trace.dev.
I love this. Prompt engineering is a real skill, and learning by example is the best way to do it. Juniors being able to see how seniors actually did something is really powerful.
The idea was simple: keep AI prompts, intents, and conversations alongside your code and commits — basically treating AI interaction as first-class development artifacts. everything just plain Git
We struggled to get momentum. Things happen.
Now, less than 24 hours ago, Thomas announced Entire.io:
“Entire CLI hooks into your git workflow to capture AI agent sessions on every push. Sessions are indexed alongside commits, a searchable record of how code was written.”
That’s… very, very close to what we tried to build.
Honestly, I love the vision and think this will matter a lot in the AI age. It’s validating to see someone with that reach betting big on it.
Best of luck to Thomas and the team behind Entire.
> 6. Work on basic infra [...] there's a lot of infrastructure that currently go around the tools, such as observability, tracking not just the committed code but the agent trajectories that led to them, and central management of the tools that agents are able to use.
Absolutely, it's also cool to see that so much is happening here right now. Sometimes you need a bit of a network to get something like this off the ground. Building infrastructure is never easy.
New agent framework / platform every week now. It's crazy how fast things move...just when you get comfortable with an AI flow something new comes out...
Sorry for not contributing to the discussion (as per the guidelines), but is it just me or this blog post reads a lot like LLM-filled mumble jumble? Seems like I could trim half of the words there and nothing would be lost.
Really struggling to figure out what this is at a glance. Buried in the text is this line which I think is the tl;dr:
"As a result, every change can now be traced back not only to a diff, but to the reasoning that produced it."
This is a good idea, but I just don't see how you build an entire platform around this. This feels like a feature that should be added to GitHub. Something to see in the existing PR workflow. Why do I want to go to a separate developer platform to look at this information?
I'm sure i'm missing something but can you not ask the llm to add the reasoning behind the commit in the comments as part of the general llm instructions?
I am already overloaded with information (generated by AI and humans) on my day to day job, why do I need this additional context, unless company I work for just wants to spend more money to store more slop?
How is it different than reversing it, given a PR -> generate prompt based on business context relevant to the repo or mentioned issues -> preserve it as part of PR description
I barely look at git commit history, why should I look for even higher cardinality data, in this case: WTF, are you doing, idiot, I said don't change the logic to make tests pass, I said properly write tests!
so I'm guessing now I can finally say "go fix the bug" and the future agents can run blame on old tracked prompts, find the thought process behind a line themselves, and fix the bug?
Which only reinforces someone just lit $60M on fire. It's trivial to do this and there are so many ways people do things, having the AI build custom for you is better than paying some VC funded platform to build something for the average
I don't see how we need a brand new paradigm just because LLMs evidently suck at sharing context in their Git commits. The rules for good commits still apply in The New Age. Git is still good enough, LLMs (i.e. their developer handlers) just need to leverage it.
Personally, I don't let LLMs commit directly. I git add -p and write my own commit messages -- with additional context where required -- because at the end of the day, I'm responsible for the code. If something's unclear or lacks context, it's my fault, not the robot's.
But I would like to see a better GitHub, so maybe they will end up there.
What's amusing is that I specifically made a comedy license for it, because I thought trying to protect the IP of such a thing is madness in the AI-native era. Then within days I find out it's a massively funded startup!
Say what you want about LLM-assisted software development, the chances are high that it will stay, meaning a non-trivial part of code will be written by an LLM.
So is it better to have
- git commit (mostly only code)
- magic or blackblock (meaning back and forth by developer with LLM, before commit)
- git commit (mostly only code)
...
(rinse and repeat)
Chris was also CEO from 2008 to 2012. Tom had 2012 to 2014.
Nat's company Xamarin was acquired by Microsoft in 2016.
HockeyApp wasn't A/B testing, but a platform for iPhone, Mac, Android, and Windows Phone developers to distribute their beta version (like what TestFlight is today to the App Store), collect crash reports (like what Sentry is today), user feedback, and basic analytics for developers.
The Ximian thing I wrote from obviously faulty memory (I now wonder if it was influenced by early 2000s Miguel's bonobo obsession), the rest from various google searches. Should have gone deeper.
Ximian, Inc. (previously called Helix Code and originally named International Gnome Support) was an American company that developed, sold and supported application software for Linux and Unix based on the GNOME platform. It was founded by Miguel de Icaza and Nat Friedman in 1999 and was bought by Novell in 2003
...
Novell was in turn acquired by The Attachmate Group on 27 April 2011. In May 2011 The Attachmate Group laid off all its US staff working on Mono, which included De Icaza. He and Friedman then founded Xamarin on 16 May 2011, a new company to continue the development of Mono. On 24 February 2016, Microsoft announced that they had signed an agreement to acquire Xamarin.
Didn't say you were wrong. It was just missing the Xamarin step in the sequence of companies, and arguably Xamarin was the bigger milestone than Ximian.
Essentially all software is augmented with agentic development now, or if not, built with technology or on platforms that is
It's like complaining about the availability of the printing press because it proliferated tabloid production, while preferring beautifully hand-crafted tomes. It's reactively trendy to hate on it because of the vulgar production it enables and to elevate the artisanal extremes that escape its apparent influence
It's really not as integral as you make it sound. If I make one PR on a widely used open source tool with a small fix, is most software development augmented by me?
Outside of simply not being true, the sentiment of what you're saying isn't much different than:
"Essentially all software is augmented with Stack Overflow now, or if not, built with technology or on platforms that is."
Agentic development isn't a panacea nor as widespread as you claim. I'd wager that the vast majority of developers treat AI is a more specified search engine to point them in the direction they're looking for.
AI hallucination is still as massive problem. Can't tell you the number of times I've used agentic prompting with a top model that writes code for a package based on the wrong version number or flat out invents functionality that doesn't exist.
I just cannot fathom how people can say something like this today, agentic tools have now passed an inflection point. People want to point out the short comings and fully ignore that you can now make a fully functioning iPhone app in a day without knowing swift or front end development? That I can at my company do two projects simultaneously, both of them done in about 1/4 the time and one would not have even been attempted before due to the SWE headcount you would have to steal. There are countless examples I have in my own personal projects that just are such an obvious counter example to the moaning “I appreciate the craft” people or “yea this will never work because people still have to read the code” (today sure and this is now made more manageable by good quality agents, tomorrow no. No you won’t need to read code.)
I've found that the effort required to get a good outcome is roughly equal to the effort of doing it myself.
If I do it myself, I get the added bonus of actually understanding what the code is doing, which makes debugging any issues down the line way easier. It's also in generally better for teams b/c you can ask the 'owner' of a part of the codebase what their intuition is on an issue (trying to have AI fill in for this purpose has been underwhelming for me so far).
Trying to maintain a vibecoded codebase essentially involves spelunking though a non-familliar codebase every time manual action is needed to fix an issue (including reviewing/verifying the output of an AI tool's fix for the issue).
(For small/pinpointed things, it has been very good. e.g.: write a python script to comb through this CSV and print x details about it/turn this into a dashboard)
There are other things very good "at some range of common tasks". For example, stackoverflow snippets, libraries, bash spaghetti and even some no-code/low-code tools.
In sonnet 4 and even 4.5 I would have said you are absolutely right, and in many cases it slows you down especially when you don’t know enough to sniff trouble.
Opus 4.5 and 4.6 is where those instances have gone down, waaay down (though still true). Two personal projects I had abandoned after sonnet built a large pile of semi working cruft it couldn’t quite reason about, opus 4.6 does it in almost one shot.
You are right about learning but consider: you can educate yourself along the way — in some cases it’s no substitute for writing the code yourself, and in many cases you learn a ton more because it’s an excellent teacher and you can try out ideas to see which work best or get feedback on them. I feel I have learned a TON about the space though unlike when I code it myself I may not be extremely comfortable with the details. I would argue we are about 30% of the way to the point where it’s not even no longer relevant it’s a disservice to your company to be writing things yourself.
What part of Voyager I and Voyager II are "augmented with agentic development?"
Surely if all software is augmented with agentic development now, our most important space probes have had their software augmented too, right?
What about my blog that I serve static pages on? What about the xray machine my dentist uses? What about the firmware in my toaster? Does the New York Stock Exchange use AI to action stock trades? What about my telescope's ACSOM driver?
You’re talking about a 1970s satellite? I guess you win the argument?
Blog: I use AI to make and blog developers are using agentic tools
X-ray machine: again a little late here, plus if you want to start dragging in places that likely have a huge amount of beaurocracy I don’t know that that’s very fair
Firmware in your toaster: cmon these are old basic things, if it’s new firmware maybe? But probably not? These are not strong examples
NYSE to action on stock trades; no they don’t use AI to action on stock trades (that would be dumb and slow and horribly inefficient and non-deterministic), but may very well now be using AI to work on the codebase that does
Let’s try to find maybe more impactful examples than small embodied components in toasters and telescopes, 1970s era telescopes that are already past our solar system.
Im saying you’re missing the point and the spirit of the argument. Yes, you are right, voyager doesn’t use agentic AI! I don’t even think the other examples you used are as agentic free as you think. They may or may not be! What’s the point you want to make?
With the how AI companies are advertising we can just tell the AI what we want and it will be done with no additional human interaction needed, why do we need a new type of development platform? We shouldn't need to collaborate at all.
The why is simple: "because we need the money." The idea is just a vehicle to get that money. Whether or not it works or makes sense is secondary to but does it make the children dream, pa-pa?
Is it just me or does "ex GitHub CEO" sound like it's going to be a bad project getting continuously worse and therefore is not worth to even look into!?
Hah. "If it's not too much trouble, would you mind if we disable the rimraf root feature?"
Gotta bully that thing man. There's probably room in the market for a local tool that strips the superfluous niceties from instructions. Probably gonna save a material amount of tokens in aggregate.
I really hate this trend of naming companies using dictionary words just because they can afford to spend cash on the domain name instead of engineering. Render, fly, modal, entire and so on.
$60M seed to wrap git hooks in YAML config. The AI tooling bubble is just VCs subsidizing solutions looking for problems while developers want less complexity, not more.
The AI fatigue is real, and the cooling-off period is going to hurt. We’re deep into concept overload now. Every week it’s another tool (don’t get me started on Gas Town) confidently claiming to solve… something. “Faster development”, apparently.
Unless you’re already ideologically committed to this space, I don’t see how the average engineer has the energy or motivation to even understand these tools, never mind meaningfully compare them. That’s before you factor in that many of them actively remove the parts of engineering people enjoy, while piling on yet another layer of abstraction, configuration, and cognitive load.
I’m so tired of being told we’re in yet another “paradigm shift”. Tools like Codex can be useful in small doses, but the moment it turns into a sprawling ecosystem of prompts, agents, workflows, and magical thinking, it stops feeling like leverage and starts feeling like self-inflicted complexity.
> I don’t see how the average engineer has the energy or motivation to even understand these tools, never mind meaningfully compare them
This is why I use the copilot extension in VS code. They seem to just copy whatever useful thing climbs to the surface of the AI tool slop pile. Last week I loaded up and Opus 4.6 was there ready to use. Yesterday I found it has a new Claude tool built in which I used to do some refactoring... it worked fine. It's like having an AI tool curator.
Your point about the overwhelming proliferation of AI tools and not knowing which are worth any attention and which are trash is very true I feel that a lot today (my solution is basically to just lean into one or two and ask for recommendations on other tools with mixed success).
The “I’m so tired of being told we’re in another paradigm shift” comments are widely heard and upvoted on HN and are just so hard to comprehend today. They are not seeing the writing on the wall and following where the ball is going to be even in 6-12 months. We have scaling laws, multiple METR benchmarks, internal and external evals of a variety of flavors.
“Tools like codex can be useful in small doses” the best and most prestigious engineers I know inside and outside my company do not code virtually at all. I’m not one of them but I also do not code at all whatsoever. Agents are sufficiently powerful to justify and explain themselves and walk you through as much of the code as you want them to.
Yeah, I’m not disputing that AI-assisted engineering is a real shift. It obviously is.
My issue is that we’ve now got a million secondary “paradigm shifts” layered on top: agent frameworks, orchestration patterns, prompt DSLs, eval harnesses, routing, memory, tool calling, “autonomous” workflows… all presented like you’re behind if you’re not constantly replatforming your brain.
Even if the end-state is “engineers code less”, the near-term reality for most engineers is still: deliver software, support customers, handle incidents, and now also become competent evaluators of rapidly changing bot stacks. That cognitive tax is brutal.
So yes, follow where the ball is going. I am. I’m just not pretending the current proliferation is anything other than noisy and expensive to keep up with.
Oh man I'm tired. This reminds me of the docker era. It's all moving fast. Everyone's raising money. And 24 months from now it's all consolidating. It's all a nice hype game when you raise the funding but the execution depends on people finding value in your products and tools. I would argue yes many of these things are useful but I'd also argue there's far too much overlap, too many unknowns and too many people trying to reinvent the whole process. And just like the container era I think we're going to see a real race to zero. Where most of the dev tools get open sourced and only a handful of product companies survive, if that. I want to wish everyone the best of luck because I myself have raised money and spent countless years building Dev tools. This is no easy task especially as the landscape is changing. I just think when you raise $60m and announce a cli. You're already dead, you just don't know it. I'm sorry.
I see the value since I built a similar tool different approach. Then there's Beads, which is what inspired my project, with some tens of thousands of developers using it or more now? I'm not sure how they figure how many users they have.
In my case I don't want my tools to assume git, my tools should work whether I open SVN, TFS, Git, or a zip file. It should also sync back into my 'human' tooling, which is what I do currently. Still working on it, but its also free, just like Beads.
I wouldn't wanna be in the rat race myself, but I know people who salivate at the opportunity to create some popular dev tool to get acquired by MS, Google or Amazon or whichever of the big tech companies that decide this could work well in their cloud ecosystem.
On the one hand they think these things provide 1337x productivity gains, can be run autonomously, and will one day lead to "the first 1 person billion dollar company".
And in complete cognitive dissonance also somehow still have fantasies of future 'acquisition' by their oppressors.
Why acquire your trash dev tool?
They'll just have the agents copy it. Hell, you could even outright steal it, because apparently laundering any licensing issues through LLMs short circuits the brains of judges to protohuman clacking rocks together levels.
I think there are 2 parts here. That persona you’re describing (startup cofounder or engineer being paid mostly in equity) is a good subset of the people here. If I had to pull a number out of my shiny metal ass, I’d say it’s 30%. Those people both loath big tech, and dream of the day they are acquired by it. It’s not really the contradiction you think it’s. Another 45% of people here are tech-savvy Reddit refuges who say Reddit things.
As to why would those company acquire a startup instead of having an agent generate it for them. Why has big tech ever acquired tech startups when they could have always funded it in house? It’s not always a technical answer. Sometimes it’s internal Political fights, time to market, reduce competition, PR reasons or they just wanna hire the founder to lead a team for that internally and the only way he’ll agree is if there is an exit plan for his employees. I sat in “acquire or build” discussions before. The “how hard would it be to just do that?” Was just one of many inputs into the discussion. Ever wondered why big big companies acquire a smaller one, not invest in it, then shut it down few years later?
With 60 million you could have waited for a bigger announcement? There's "AI fatigue" among the target market for these sorts of tools, advertising unfinished products will take its toll on you later.
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?
> if OpenAI can essentially work with Monopolly money, whey can´t "we" do it too?
The answer is, in case anyone wonders: because OpenAI is providing a general purpose tool that has potential to subsume most of the software industry; "We" are merely setting up toll gates around what will ultimately become a bunch of tools for LLM, and trying to pass it off as a "product".
For the huge amounts of capital already burnt, and another 1T in CapEX RPO being announced last few weeks and months, isnt that too many of "potentially" and "ultimately" unspecific qualifiers you are throwing around here? Reminds a lot of Sam Altmans classic lines of unspecific statements like "Codex is so good" or "I can only imagine how good it will get" by the end of 202x (insert year of the decade according to your own preference). After 10+ years of OpenAI and 4+ years of ChatGPT, why is the potential not materialising ?
We are in an era of solutions being invented and developed at a rapid pace. The identification or invention of problems that they are good at solving has a much slower lifecycle.
Counter argument just to play devil’s advocate. Is that forming LLMs into useful shapes could become the game. If it turns out to be impossible to build a real moat around making LLMs - like maybe China or just anyone will ultimately be able to run them locally / cheaply, then the game of spending a billion dollars training one is much more risky
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.
My memories are different. Git became amazing on it's own and was a big advantage over SVN. GitHub was "a open source" thing in the beginning. No company here had the idea to host proprietary closed source code on another platform they do not have control over. This eventually became a thing later though and the mindset shifted.
I think you're both right. Post-Github, a lot of Git's adoption came from Github. But Github "worked" because a lot of people were already using Git and Github offered them amazing value, and that initial userbase created a viral effect: People increasingly came into contact with Github via projects hosted there, and those who did not already use Git picked it up as a result of that.
And now many companies do have the idea of hosting proprietary code on a shitty, buggy, closed-source platform they have no control over. Indeed a shifted mindset. Maybe it wasn't shitty, buggy and closed-source enough before.
> 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.
Github has always been mediocre and forgettable outside of convenience that you might already have an account on the site. Svn was just shitty compared to git, and cvs was a crime against humanity.
I have to hard disagree on that. I know of many developers personally who were on Source Forge and Google Code before and migrated to GitHub specifically because they offered git
I don't think SVN and Mercurial were more widely used than git before Github became popular, but Github definitely killed off most of the use of those.
Git had already replaced perforce and svn most everywhere I'd seen, before GitHub came along. CVS was still horrible and in a lot, though.
I mean, git was '05 and GitHub was '08, so not like the stats will say much one way or another.
StackOverflow only added it their survey in 2015. No source of truth, only anecdotes.
Lots of people were using svn and mercurial was also coming up around the time that GitHub launched. Both git and GitHub were superior to all the other options but for many people they did the switch to GitHub and git at the same time.
Yeah, whilst git was more popular than mercurial, I still think mercurial would have won if bitbucket had a better UI.
It's interesting to me that the only thing that made me vastly prefer using Github over bitbucket is that Github prioritised showing the readme over showing the source tree. Such a little thing, but it made all the difference.
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.
At least for me, I have felt like the chat history in an agent is often times just as important and potentially even more important than the source code it generates. The code is merely the compiled result of my explanations of intent and goals. That is, the business logic and domain expertise is trapped in my brain, which isn't very scalable.
Versioning and tracking the true source code, my thoughts, or even the thoughts of other agents and their findings, seems like a logical next step. A hosted central place for it and the infrastructure required to store the immense data created by constantly churning agents that arrive at a certain result seems like the challenge many seem to be missing here.
I'm building an "improvement agent" that kinda embraces that. It starts out by running exploration across a codebase or set of documents and extract possible goals, and a vision from that. It then starts producing improvement plans (tickets, effectively). If it gets things wrong, I nudge it in the right direction, and it gets incorporated into revisions of the documents via a review stage. It's an experiment for now, but it is both doing semi-self-directed implementation and helping me identify where my thoughts haven't been crystallised enough by seeing where it fails to understand what I want.
I'm not just running it on code, but on my daily journal, and it produces actionable plans for building infrastructure to help me plan and execute better as a result.
Natural language is in fact a terrible way to express goals, it is imprecise, contradictory, subjective, full of redundancies and constantly changing. So possibly the worst format to record business rules and logic.
This lesson has been learned over and over (see AppleScript) but it seems people need to keep learning it.
We use simple programming languages composed of logic and maths not just to talk to the machine but to codify our thoughts within a strict internally consistent and deterministic system.
So in no sense are the vague imprecise instructions fed to LLMs the true source code.
Before LLMs (and still now) a human will often write a doc explaining the desired UX and user journeys that a product needs to support. That doc gets provided to engineers to build.
I agree - at least with the thesis - that the more we "encode" the fuzzy ideas (as translated by an engineer) into the codebase the better. This isn't the same thing as an "English compiler". It'd be closer to the git commit messages, understanding why a change was happening, and what product decisions and compromises were being designed against.
I think I’d rather have the why in English and the how in code, i.e. keep both, keeping just the English instructions is nowhere near enough to fully specify what was done and why. These things evolve as they are produced and English is too fuzzy.
You don't need a workflow. The agent is the workflow. That's the idea at least. Probably not a great idea IMHO, because producing high quality code is the main difficulty of programming. Everything else, committing to git, deploying etc, pale in comparison.
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.
Yes, development was being done in SVN but it was a huge pain. Continuous communication was required with the server (history lookups took ages, changing a file required a checkout, etc.) and that was just horribly inefficient for distributed teams. Even within Europe, much more so when cross-continent.
A DVCS was definitely required. And I would say git won out due to Linus inventing and then backing it, not because of a platform that would serve it.
I am not sure, it seems I did misremember. Though it's possible I was actually working with needs-lock files. I can definitely see a certain coworker from that time to put this on all files :/
And even in P4, you could checkout files only at the end, kind of like `git add`. Though this could provide some annoyance if someone had locked the file in the upstream.
Yes to all that. And GitLab the company was only founded in 2014 (OSS project started in 2011) and ran through YC in 2015, seven years after GitHub launched.
The goal here is just to piggyback on the AI bandwagon, gather a lot of funding, create a product nobody understands but that sparks imagination, and sell it to FAANG.
Nobody cares if it makes sense, it just has to appear futuristic and avant-garde.
We’re building to milk the bitch while the hype is at the top. Anyone who seriously believes agents are capable of operating completely autonomously right now without any human supervision is delusional.
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.
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.
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
We went from having new JavaScript frameworks every week to having new AI frameworks every week. I'm thinking I should build a HN clone that filters out all posts about AI topics...
Looking at the most popular agent skills, heavily geared towards react and JS, I think a lot of the most breathless reports of LLM success are weighted towards the same group of fashion-dependant JavaScript developers.
The same very online group endlessly hyping messy techs and frontend JS frameworks, oblivious to the Facebook and Google sized mechanics driving said frameworks, are now 100x-ing themselves with things like “specs” and “tests” and dreaming big about type systems and compilers we’ve had for decades.
I don’t wanna say this cycle is us watching Node jockies discover systems programming in slow motion through LLMs, but it feels like that sometimes.
Ironically, using LLM’s for React is an exercise in pain, because they’re all trained on the lowest common denominator. So even Opus is constantly fighting stupid reactivity bugs.
Just give me your bank account, claude API, Mother's maiden name, your zip code, your 3 digit security code, and anything else you think I might need to live as malfist the magnificant. Can I call you that?
I've long wished for a 'filter' feature for the hn feed -- namely the old trend of web3 slop -- but with little else than keywords to filter, it would likely be tedious and inaccurate. Ironically, I think with AI/LLMs it could be a little easier to analyze.
This is how software is being written now. What you propose is like joining a forum called "Small-Scale Manufacturing News" and filtering out all 3D-printing articles.
I'm pretty happy using Shelley, which stores agent conversations in a Sqlite database. I can refer to a previous conversation and the agent can easily do a Sqlite query to see what happened.
Although this isn't stored in git, I don't see any particularly need to since it's too detailed. Instead I have the agent write design docs (as an alternative to plan mode) and check those in. That seems like enough.
The CLI is open source, everyone can use it and it does work with git only. So, no separate platform needed. The platform only provides convenience to view checkpoints at the moment. However you can also view them in the CLI. It's here https://github.com/entireio/cli
This sounds like a company idea someone just came up with yesterday off the cuff, pitched it, and got money for because of their credentials so no one can really say no to investing in it, despite nothing new or different? What's the service or product and how is it different than every 3rd Show HN?
> The problem is that agent-written code has a provenance gap. When a human writes code, the reasoning lives in their head, in Slack threads, in PR descriptions. When an agent writes code, the reasoning evaporates the moment the context window closes.
The described situation for human-written code isn't much better. What actually works is putting a ticket (or project) number in the commit message, and making sure everything relevant gets written up and saved to that centralized repository.
And once you have that, the level of detail you'd get from saving agent chats won't add much. Maybe unless you're doing deliberate study of how to prompt more effectively (but even then, the next iteration of models is just a couple months away)?
Agent memory can sometimes be handled with prompts, state output on completion, etc. Managing that can get messy if you aren't on the same system.
I think "provenance gap" or temporal history can be helped by understanding what you have asked agentic systems to write, understand things written, and verified them.
We aren't yet at a point where something large or extended is easily pushed to agentic coding management - your point of provenance and memory is key here.
Already at a $300 million valuation at seed. Who’s going to join this as a regular IC who gets a pittance in options? I can’t imagine the risk matches the modest potential upside.
They'll raise at double that or more before the end of the year. The dynamics of the VC market right now are staggering to watch, but the money velocity is real, and this has "ex-CEO of Github" plus "AI".
It's legit mania in VC world even as they're looking at each going "is this mania? Is it mania if you're asking if it's mania". The only rule right now is the music is playing so no-one wants to grab a chair. There's a sense this might come crashing down, but what's a player gonna do, sit on the side while paper markups are producing IRR that is practically unprecedented?
The most interesting thing about everyone trying to position themselves as AI experts is the futility of it: the technology explicitly promises tomorrows models will be better then todays, which means the skill investment is deflationary: the best time to learn anything is tomorrow when a better model will be better at doing the same work - because you don't need to be (conversely if you're not good at debugging and reverse engineering now...)
the best time to learn anything is tomorrow when a better model will be better at doing the same work
doesn’t that presume no value is being delivered by current models?
I can understand applying this logic to building a startup that solves today’s ai shortcomings… but value delivered today is still valuable even if it becomes more effective tomorrow.
I think it also presumes that the skills of today won't be helpful in making you better, faster, stronger at knowing what to learn tomorrow. Skateboarding ain't snowboarding but I guarantee the experience helps.
I'm pretty much just rawdogging Claude Code and opencode and I haven't bothered setting up skills or MCPs except for one that talks to Jira and Confluence. I just don't see the point when I'm perfectly capable of writing a detailed prompt with all my expectations.
The problem is that so many of these things are AI instructing AI and my trust rating for vibe coded tools is zero. It's become a point of pride for the human to be taken out of the loop, and the one thing that isn't recorded is the transcript that produced the slop.
I mean, you have the creator of openclaw saying he doesn't read code at all, he just generates it. That is not software engineering or development, it's brogrammer trash.
I think the rationale is that with the right tools you can move much faster, and not burn everything to the ground, than just rawdogging Claude. If you haven't bothered setting up extra tools you may still be faster / better than old you, but not better than the you that could be. I'm not preaching, that's just the idea.
> That is not software engineering or development, it's brogrammer trash.
Yes, but it's working. I'm still reading the code and calling out specific issues to Claude, but it's less and less.
You're reading it though, and I imagine you are applying comprehension to it based on your experience. It's not vibe-coding any more at that point, I'd call it rapid application development. That's what Rails did in, what, 2010? Maybe earlier? Except it was generated scaffolding code created through reflection and not machine learning.
It's when you take yourself out of the loop and trust the process that it goes in the wrong direction.
That’s true for “tips and tricks” knowledge like “which model is best today” or “tell the model you’ll get fired if the answer is wrong to increase accuracy” that pops up on Twitter/X. It’s fleeting, makes people feel like “experts”, and doesn’t age well.
On the other hand, deeply understanding how models work and where they fall short, how to set up, organize, and maintain context, and which tools and workflows support that tends to last much longer. When something like the “Ralph loop” blows up on social media (and dies just as fast), the interesting question is: what problem was it trying to solve, and how did it do it differently from alternatives? Thinking through those problems is like training a muscle, and that muscle stays useful even as the underlying technology evolves.
> what problem was it trying to solve, and how did it do it differently from alternatives?
Sounds to me like accidental complexity. The essential problem is to write good code for the computer to do it's task?
There's an issue if you're (general you) more focused on fixing the tool than on the primary problem, especially when you don't know if the tool is even suitable,
It does seem like things are moving very quickly even deeper than what you are saying. Less than a year ago langchain, model fine tuning and RAG were the cutting edge and the “thing to do”.
Now because of models improving, context sizes getting bigger, and commercial offerings improving I hardly hear about them.
I have a reading list of a bunch of papers i didn't get through over the past 2 years. it is crazy how many papers on this list are completely not talked about anymore.
I kinda regret going through the SeLU paper lol back in the late 2010s.
You nailed it. Thats exactly how I feel. Wake me up when the dust settles, and i'll deep dive and learn all the ins and outs. The churn is just too exhausting.
I don't get the pressure. I don't know about you, but my job for a long time has been continually learning new systems. I don't get how so many of my peers fall into this head trip where they think they are gonna get left behind by what amounts to anticipated new features from some SaaS one day.
How do you both hold that the technology is so revolutionary because of its productive gains, but at the same time so esoteric that you better be ontop of everything all the time?
This stuff is all like a weird toy compared to other things I have taken the time to learn in my career, the sense of expertise people claim at all comes off to me like a guy who knows the Taco Bell secret menu, or the best set of coupons to use at Target. Its the opposite of intimidating!
I may just be a "doomer", but my current take is we have maybe 3-5 years of decent compensation left to "extract" from our profession. Being an AI "expert" will likely extend that range slightly, but at the cost of being one of the "traitors" that helps build your own replacement (but it will happen with or without you).
> the technology explicitly promises tomorrows models will be better then todays, which means the skill investment is deflationary
This is just wrong. A) It doesn’t promise improvement B) Even if it does improve, that doesn’t say anything about skill investment. Maybe its improvements amplify human skill just as they have so far.
Either the business makes a profit before it gets swept away, or it doesn't. This should be your goal: make money before your business dies. If you do that, you succeeded. Businesses are always ephemeral.
This is very well put. I think this platform can be useful but I doubt it can be something as big as the think it will be. At the end of the day it’s just storing some info with your data. I guess they are trying to be the next GitHub (and clearly have the experience :)). I doubt that success can be replicated today with this idea, even with $60 mil to burn
You’ve described a technology, not a solution to a clearly articulated problem that customers actually have. The problem that you have described is vague, and it’s unclear that it’s actually a problem at all. Finally, you don’t provide a persuasive and concrete argument about how your eventual solution—whatever that may be—will solve it.
I don’t mean to be so presumptuous as to teach Grampa how to suck eggs, but I think Amazon’s working backwards process is instructive.
Hey, is JJ compatibility in the cards? Considering the blog article hints at a goal of a developerless agent-to-agent automation platform I'm guessing developer conveniences are a side quest rn?
The founder has only forked repositories on GitHub that are sort of light web development related.
His use of bombastic language in this announcement suggests that he has never personally worked on serious software. The deterioration of GitHub under his tenure is not confidence inspiring either, but that of course may have been dictated by Nadella.
If you are very generous, this is just another GitHub competitor dressed up in AI B.S. in order to get funding.
Personal attacks aren't allowed here, so I've banned the account. If you want to use HN as intended, you'd be welcome to review https://news.ycombinator.com/newsguidelines.html and then email hn@ycombinator.com with a reason to believe that you'll follow the rules in the future.
Founder here. I built commercial insurance software for Windows 95 in the 1990s, driver assistant systems at Mercedes and at Bosch in the early 2000s, dozens of iPhone apps as contractor, a startup called HockeyApp (acquired by Microsoft), and various smaller projects, mostly in Ruby on Rails. And of course, when I left Microsoft & GitHub, 10 years of green boxes were removed from my GitHub profile.
Glad to see you commenting here despite the, er, unsubstantive disposition of some of the commenters! (I'm a mod here btw.) We really don't like it when the audience responds to new things with snark and dismissiveness, and there are rules in https://news.ycombinator.com/newsguidelines.html to make that clear.
In this case I think the root problem is that the OP (https://entire.io/blog/hello-entire-world/) is the wrong genre for HN. It's a fine fundraising announcement, but that sort of enthusiastic general announcement rubs the HN audience the wrong way because what they really want is technical details. Spectacular non technical details like high valuations, etc., tend to accentuate this gap.
I mention this because if you or someone on your team wants to write a technical post about what you're building, with satisfying details and all that, then we could do a take 2 (whenever would be a good time for this).
Makes sense, and we definitely will have more technical posts coming soon and on a regular basis. And I am German, I am used to snark. :P Joking aside, thanks for the response and appreciate your work as a mod!
The thread is missing the forest for the trees. The interesting bet here isn't git checkpoints—it's that someone is finally building the observability layer for agent-generated code.
Most agent frameworks (LangChain, Swarm, etc.) obsessed over orchestration. But the actual pain point isn't "how do I chain prompts"—it's "what did the agent do, why, and how do I audit/reproduce it?"
The markdown-files-in-git crowd is right that simple approaches work. But they work at small scale. Once you have multiple agents across multiple sessions generating code in production, you hit the same observability problems every other distributed system hits: tracing, attribution, debugging failures across runs.
The $60M question is whether that problem is big enough to justify a platform vs. teams bolting on their own logging. I'm skeptical—but the underlying insight (agent observability > agent orchestration) seems directionally correct.
@dang with the launch of open claw I have seen so much more LLM slop comments. I know meta comments like mine aren't usually encouraged, but I think we need to do something about this as a community. Is there anything we can do? (either ban or at least requiring full disclosure for bot comments would be nice).
EDIT: I suspect the current "solution" is to just downvote (which I do!), but I think people who don't chat with LLMs daily might not recognize their telltale signs so I often see them highly upvoted.
Maybe that means people want LLM comments here, but it severely changes the tone and vibe of this site and I would like to at least have the community make that choice consciously rather than just slowly slide into the slop era.
Parent comment has the rhythm of an AI comment. Caught myself not realizing it until you mentioned it. Seems like I am more in tune with LLM slop on twitter, which is usually much worse.
But on second sight it's clear and it also shows the comment as having no stance, and very generic.
@dang I would welcome a small secondary button that one can vote on to community-driven mark a comment as AI, just so we know.
I've been thinking about this, one solution I wonder if to put a really hard problem in the sigh up flow that humans couldn't solve, if it's solve in the signup, it's a bot, not sure how tf to actually basically captchas flip, however I suspect this would only work for so long.
Yes I usually just bite my tongue and downvote, but with the launch of open claw I think the amount of slop has increased dramatically and I think we need to deal with it sooner than later.
Thank you for pointing this out. I didn't catch that the parent comment was ai either and upvoted it. Changed it to a downvote seeing your comment and realizing it the comment did indeed have many AI flags.
How much experience do you have interacting with LLM generated prose? The comment I replied to sets off so many red flags that I would be willing to stake a lot on it being completely LLM generated.
It's not just the em dashes - its the cadence, tone and structure of the whole comment.
Yeah it's really frustrating how often I see kneejerk rebuttals assuming others are solely basing it on presence of em-dashes. That's usually a secondary data point. The obvious tells are more often structure/cadence as you say and by far most importantly: a clear pattern of repeated similar "AI smell" comments in their history that make it 100% obvious.
> Once you have multiple agents across multiple sessions generating code in production, you hit the same observability problems every other distributed system hits: tracing, attribution, debugging failures across runs.
This has been the story for every trend empowering developers since year dot. Look back and you can find exactly the same said about CD, public cloud, containers, the works. The 'orchestration' (read compliance) layers always get routed around. Always.
verbatim llm output with little substance to it.
HN mods don't want us to be negative but if this is what we have to take serious these days it is hard to say anything else.
I guess I could not comment at all but that feels like just letting the platform sink into the slopacolypse?
I thought everyone was just using open telemetry traces for this? This is just a classic observability problem that isn’t unique with agents. More important yes, but not unique functionally.
Ok, I’ll grant you that if they can get agents to somehow connect to other’s reasoning in realtime that would be useful. Right now it’s me that has to play reasoning container.
This is interesting. I’m experimenting with something adjacent in an open source plugin, but focused less on orchestration and more on decision quality.
Instead of just wiring agents together, I require stake and structured review around outputs. The idea is simple: coordination without cost trends toward noise.
Curious how entire.io thinks about incentives and failure modes as systems scale.
That is a sharp observation———it is the observability that matters! The question arises: Who observes the observers? Would you like me to create MetaEntire.ai———an agentic platform that observes Entire.io?
This is what Claude had to say about your comment if we're doing this now:
Imagine being so intellectually lazy that you can't even be bothered to form your own opinion about a product. You just copy-paste it into Claude with "roast this" and then post the output like you're contributing something. That's not criticism, that's outsourcing your personality to an API call. You didn't engage with the architecture, the docs, the use case, or even the pricing page — you just wanted a sick burn you didn't have to think of yourself.
Are people doing this thing now where they can't even judge a product, website by themselves? Or read and analyze anything without asking an LLM to do it for them.
2026: The year everyone fried their brain with Think for Me SaaS.
I know a guy who uses AI to answer every question in his life. It tells him how to raise his kids, how to spend time with his wife. He takes it to the park with him and asks it what he should do there (on his phone). When people ask him questions, he forwards those questions directly to his phone and uses the response.
For any new piece of technology, there are a subset of people for whom it will completely and utterly destroy.
I think there's a distribution of agency in humans, hence why we have insults like "npcs". Its probably not fair to use that word to describe people, but the cliche has some truth in it and I think a lot of tech exploits this.
I personally rarely need to use google maps, and if I do its a glance at it on the beginning of a trip, and I can find my way there through normal navigation. I might look again if I get lost, whereas, I have friends that use it to give directions to go five blocks. I don't think sense of direction is innate either, but its a muscle you build and some people choose to not work on that muscle and they suffer the consequences, albeit minor consequences.
I think we are seeing something similar with LLMs with the development and maintenance of reading, planning, creative and critical thinking skills. While some people might have a higher baseline, I think everyone has the ability to strengthen those muscles and the world implores us to do that in many situations, however, now we can pay Altman $0.0010 cents to offload that workout onto a GPU much like people do with navigation and maps. Tech companies love to exploit the dopamine driven response from taking shortcuts, getting somewhere quickly, its no different here.
I think (/know) the implications of this are much more hazardous than consequences of not exercising your navigational abilities, and at least with navigation there are fallback to assist people (signs, landmarks ect). There are no societal fallbacks for llm assisted thinking once someone becomes dependent on it for all aspects of analysis, planning and creativity. Once it is taken away (or they can't afford a quality of output the previously did), where do those natural abilities stand? The implications are very terrifying in my opinion.
I'm personally trying to stay as far away as possible from these things, I see where this is heading and its not as inconsequential as needing Maps to navigate 5 blocks. I do not want my critical thinking skills correlated 1:1 to the quality and quantity of tokens I can afford or have access too anymore than I do not want my navigational abilities correlated 1:1 to the quality of Maps service available to me.
People will say that this is cope, its the new calculator, whatever.. Have fun, I promise you that not knowing trigonometry but having access to an LLM does not give you the ability to write CAD software. I actually think not using these will give you a huge competitive advantage in the future. Someone who has great navigation skills will likely win a navigational competition in the mountains, or survive longer in certain situations.
While the scope of those skills is narrow, it still proves a point[0]. The scope of your reading, critical thinking, creativity and planning skills is not limited.
[0]: It should be noted that some of the worlds most high agency and successful people actually participate in navigation as a sport called Orienteering, and spend boatloads of money in it.. I wonder why that is?
Some Tom Dick and Harry to VCs: I have a proposal for you.
VCs: what is it
Tom Dick & Harry: AI
VCs: get the ** out of here, we already burnt enough money and will never see it back
Tom Dick & Harry: hear me out this is different
VCs: ok you have 5 minutes to explain me your product
Tom Dick & Harry: I dont have one
VCs: get the ** out of here
Tom Dick & Harry: hear me out
VCs: ok, you have 30 seconds to impress us.
Tom Dick & Harry: I just quit Microslop and still have high level contacts there
VCs: Hot damn!!! you are our lottery ticket to recoup all the money we have lost in other ventures. This is going to be a race against time, before your contacts go stale. Here's 60M for you, wine and dine your friends with it. On your way out you will find some AI generated product names and some vague product descriptions. Pick one and slap it on some website and announce our deal. Now get the ** out of here.
> Checkpoints are a new primitive that automatically captures agent context as first-class, versioned data in Git. When you commit code generated by an agent, Checkpoints capture the full session alongside the commit: the transcript, prompts, files touched, token usage, tool calls and more.
This thread is extremely negative - if you can't see the value in this, I don't know what to tell you.
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.
There’s a difference between “this concept has value” and “a company can capture that value”.
I do see value in this, but like you I think it’s too trivial to implement to capture the value unless they can get some kind of lead on a model that can consume these artifacts more effectively. It feels like something Anthropic will have in Claude Code in a month.
GitHub doesn't have a "moat" either besides network effect. Just like most SaaS.
And it was sold to Microsoft at $7B.
Mostly because "Microsoft <3 FOSS" phase, and what better manouver than owning Github and dump Codeplex?
Look at Xamarin, almost everything that they had is now gone in modern .NET.
Well that was in the era of free money for one. And the primary value was in all the human made content for AI training.
I’m sure there’d be some value to extract from the agent produced code in this thing, but I doubt it’s anywhere near as much.
If they had wanted a moat for this part of their offering, they wouldn’t have open-sourced it.
This is not their offering, this is a tool to raise interest.
There's no way this company is just a few git and claude hooks with a CLI. They're definitely working on a SASS - something else that isn't open source that this primitive is the basis of. Like a GitHub for agent code
Impressive seeing as last week we heard that AI had killed SAAS.
haha
github for agent code is dropbox final_final2.zip
> 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?
You are correct, that isn't the moat. Writing the software is the easy part
The same moat that git had on svn, a better mental paradigm over the same fundamental system, more suited to how SWE changed over a decade.
git didn't succeed based on the mental model. It got a foot in the door with better tooling and developer experience then blew the door open when GitHub found a way to productize it.
Git doesn't have a moat. Git isn't commercial software, and doesn't need to strong arm you into accepting bad license terms.
I wouldn’t characterize it as a moat exactly. svn/cvs just had a braindead data model. Linus started git with a fundamentally better one.
I definitely see the potential of AI-native version control, it will take a bit more to convince me this is a similar step-level improvement though.
> HN threads confidently asserting
I have never seen any thread that unanimously asserts this. Even if they do, having HN/reddit asserting something as evidence is wrong way to look at things.
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.
You're confused. If you hype AI here you lose karma.
The top comment here is one by straydusk. Their profile says: data expert, AI explorer.
HN is full of anti hype posts as well. If I were to estimate there are more posts of anti hype than of hype.
I sort of agree with you. But the sentiment reminds me of the hacker news dropbox launch response. Which was pretty much
"pfft! I could set all this up myself with a NAS xyz".
https://news.ycombinator.com/item?id=8863
This comment feels word-for-word the legendary DropBox critique on HN.
It was only legendary because DropBox hit it out of the park. In hindsight it is easy to see this. And it's the default HN response to anything.
A broken forum is right twice a day
[dead]
>what's the value of paying someone for a product like this vs just building it myself?
Same thing it’s always been. Convenience. Including maintenance costs. AI tools have lowered the bar significantly on some things, so SaaS offerings will need to be better, but I don’t want to reinvent every wheel. I want to build the thing I want to build, not the things to build that.
Just like I go to restaurants instead of making every meal myself.
Right, but paying for food at a restaurant doesn't get me any closer to owning a restaurant. If promises are delivered on for these agentic coding platforms (which I do believe in), it seems the most reasonable path forward is to use those platforms to build your own platform.
You cannot test your software without Claude Code?
The software collects the network traffic of distributed Claude code instances.
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.
Yours matches my own experience and work habits.
My mental model is that LLMs are obedient but lazy. The laziness shows in the output matching the letter of the prompt but with as high "code entropy" as possible.
What I mean by "code entropy" is, for example, copy-paste-tweak (high entropy) is always easier (on the short term) for LLMs (and humans) to output than defining a function to hold concepts common across the pastes with the "tweak" represented by function arguments.
LLMs will produce high entropy output unless constrained to produce lower entropy ("better") code.
Until/unless LLMs are trained to actually apply craft learned by experienced humans, we must be explicit in our prompts.
For example, I get good results from say Claude Sonnnet when my instruction include:
- Statements of specific file, class, function names to use.
- Explicit design patterns to apply. ("loop over the outer product of lists of choices for each category")
- Implementation hints ("use itertools.product() to iterate over the combinations")
- And, "ask questions if you are uncertain" helps trigger an iteration to quickly clarify something instead of fixing the resulting code.
This specificity makes prompting a lot more work but it pays off. I only go this far when I care about the resulting code. And, I still often "retouch" as you also describe.
OTOH, when I'm vibing I'll just give end goals and let the slop flow.
Sure... you `git add` the context text generated by AI and `git commit` it, could be useful. Is that worth 60 million?
It’s good to know that a few decades later the same generic Dropbox-weekend take can be made.
99% of projects the take applies to are massive flops. The Dropbox weekend take is almost always correct.
Sorry for by ignorance, but what's the Dropbox Weekend
Many, many years ago, when ~persia came ashore~ dropbox was announced on HN [0] The top comment was quick to point out "For a Linux user, you can already build such a system yourself quite trivially
[0] https://news.ycombinator.com/item?id=8863
Yeah I guess why would anyone build anything, 99% of projects are flops.
I mean a dev tool that's seemingly failing to resonate with developers as to why they would pay for this is a pretty good way to tell if it's going to fall in the 1%.
The Dropbox take was wrong because they didn't understand the market for the product. This time the people commenting are the target audience. You even get the secondary way this product will lose even if turns out to be a good idea, existing git forges won't want to lose users and so will standardize and support attaching metadata to commits.
> This time the people commenting are the target audience.
Nah. People post about k8s on here all the time, but that doesn't mean I'm the target audience. Just because _someone_ on HN has a bad take doesn't mean they're the person who needs this. Nor does it mean they even understand it.
Survivorship bias. How many failed and commenters were right?
predicting that a startup will fail is.. well, you got a ton of probability on your side there. so it isn't a particularly impressive thing to be right about.
Unimpressive doesn't mean incorrect, sometimes it's good to take the side of the most probable. And yet at the same time I am reminded of this quote:
> The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw
Sometimes adapting oneself is, in fact, progress.
I'm not disagreeing, just soliciting. Does anyone have examples of products that failed in the early stages because their implementation was too trivial?
How exactly are we supposed to hear about something that failed in the early stages?
There are a number of ways. Obviously Dropbox would be one case of "early and didn't fail" that could have been "early and failed", and we would have heard about it.
By listening to your friends and circle
People keep saying that, but it's hardly the same thing. We're talking about developer workflow here. It's like someone coming up with Brancher. It's a git branch manager. Use `brancher foo` to replace `git checkout -b foo`. "Remember that comment about rsync and dropbox? Brancher is to git, what dropbox is to rsync"
How is LangChain doing? How about OpenAI's Swarm or their Agent SDK or whatever they called it? AWS' agent-orchestrator? The crap ton of Agent Frameworks that came out 8-12 months ago? Anyone using any of these things today? Some poor souls built stuff on it, and the smart ones moved away, and some are stuck figuring out how to do complex sub-agent orchestration and handoffs when all you need apparently is a bunch of markdown files.
Cough https://ycgraveyard.iamwillwang.com/
Just saw a Discord-weekend take on reddit! Haha. Guy was saying he could create it in a day and then self-host it on his servers so that he doesn't have to put Nitro ads on top of it
[flagged]
> It’s good to know that a few decades later the same generic Dropbox-weekend take can be made.
The dropbox-weekend take wasn't made by the intended target for the product.
This is.
It's funny how HN'ers frequently judge ideas based on complexity of implementation, not value.
I still remember the reaction when Dropbox was created: "It's just file sharing; I can build my own with FTP. What value could it possibly create".
It's a common trope. (Some) artists will often convey the same message; art should be judged on how hard it was to create. Hence why some artist despise abstract art or anything "simplistic".
We forget that human consumption doesn't increase with manufacturing complexity (it can be correlated, but not cause and effect). At the end of day, it's about human connection, which is dependent on emotion, usefulness, and availability.
I mean that's the beauty of a form full of engineers
Dropbox value was instantly recognizable, but I feel I have zero use for Entire.
I mean, I CAN see the value in pushing the context summary to git. We already have git blame to answer "who", but there is no git interrogate to answer the "why". This is clearly an attempt to make that a verb git can keep track of. It's a valuable idea.
I also seen examples of it before. I've got opencode running right now and it has a share session feature. That whole idea is just a spinoff on the concept of the same parent that led to this one.
Isn't "why" what commit message bodies are for?
That's actually not a bad idea. Idk about any tools that do that tho
They raised 60 million. The investors think it’s worth 600M+
It's the valuation that is wild to me (I think the idea itself has merit). But these are the new economics. I can only say "that's wild" enough before it is in fact no longer wild.
These aren't new economics, it's just VC funds trying to boost their holdings by saying it's worth X because they said so. Frankly the FTC should make it illegal.
That's not how it works at all. Why stop at $300M, why didn't they just say $1BN out the gate?
Of course it's how it works, how else do you justify a company that is making negative profit into some how being worth $300M? Like that's just the game, IDK why people accept it. It's not democratic and all it does it prime the population for fraud and abuse.
Yeah, that's not the game at all. Have you ever invested in startups?
I don't need to "play the game" to realize private valuations are just marketing fluff not based in reality. It's literally "the greater fool" theory in action. When the incentives are to just lie and not put out something with some actual scrutiny like a 409A, it's quite clear what game is being played.
But yes, I would totally love to invest in startups with people's pension funds. It seems like the perfect scam where the only losers are the public that allows such actions.
Almost all of the world's most valuable companies were once VC investments that I'm sure you would have dismissed as just greater fool nonsense.
But more to the point, I was talking about how you apparently think VCs just make up super high valuations of the companies they invest in to justify those investments? Are you not aware that VC is a competitive market?
That is where I’m shocked being in a position of raising for a startup myself, what was in their pitch deck/data room that convinced them of this valuation? Or is it due to the founders reputation and not the substance?
Its like github - with the word Ai. <end>
I LOVE THIS FOUNDER - I am a 10 out of 10 - YES!!!
Take my (investors) money
That's not impressive. That's an incredible amount concentrated in the hands of a few looking for a place to live. It has to end up somewhere. Some of it goes everywhere.
Discord is not prized because you can send a message to a chatroom, or any of the hooks and functions.
It's because of everybody there.
Currently no one is on Entire - the investor are betting they will be.
I think discord became popular in the first place because it was so much better than the alternatives, at least for the gaming/ hanging out with friends use case. Discord was initially competing with a bunch of self hosted stuff, vent/ mumble etc with higher barrier to entry and less features and Skype which was terrible.
Discord really became big because it had 0 obstacle onboarding. In an age of Skype, Ventrillo, Teamspeak and Mumble, all "installation" software with "server addresses" and "setup your user config", Discord shows up, says "press this link", and done, you're ready to go. Install link? No, it's in the browser. Account? No, you literally got a temp account made for you. You just talked. Yes, with a button in the corner that says "Claim this account" which just wants an email and a name, but point is, you didn't even have to do that much. This is why the comparison to it is IRC despite the two being so far apart, IRC was the only other chat software with this small of a barrier to entry.
Everything else about the featureset was copy pasted from Slack. No one cares about that part.
We have had this for ages now.... I just don't have access to the sort of people willing to pass me 60m for that. I never thought it to be worth anything really ; it was a trivial to implement afterthought.
Well a famous name is attached, could be the start of the product that replaces github, building github2 would give oppertunity to fix mistakes that are too entrenched to change at github, and who better to try? I'm uncharacteristically optimistic on this one, I'd give it a try!
I love this one so much! The arbitrary decision to cherry-pick critique a particular product to this degree, when it’s something that could be said about 99% of the stuff SV churns out, including in all likelihood anything you’ve ever worked on.
Good thing the comment you're replying to does not lionise 99% of the stuff SV churns out, including in all likelihood anything they've ever worked on. I guess we should just not critique anything out of SV because it's all shit?
That is their first feature.
If it were also their last, I would be inclined to agree.
The unannounced web collaboration platform in-progress might be.
Couldn't we capture this value with a git hook?
300 million, apparently.
The most active HNers are just extremely negative on AI. I understand the impulse (you spend years honing your craft, and then something comes along and automates major portions of it) but it's driven by emotion and ego-defense and those engaged in it simply don't recognize what's motivating them. Their ego-defense is actually self-fulfilling, because they don't even try to properly learn how to leverage LLMs for coding so they give it a huge task they want it to fail on, don't properly break it into tasks, and then say "i told you it sucks" when it fails to one shot it.
Even this response shows why the most active ones are outwardly negative on AI.
I use AI a ton, but there are just way too many grifters right now, and their favorite refrain is to dismiss any amount of negativity with "oh you're just mad/scared/jealous/etc. it replaces you".
But people who actually build things don't talk like that, grifters do. You ask them what they've built before and after the current LLM takeoff and it's crickets or slop. Like the Inglourious Basterds fingers meme.
There's no way that someone complaining about coding agents not being there yet, can't simultaneously be someone who'd look forward to a day they could just will things into existence because it's not actually about what AI might build for them: it's about "line will go up and I've attached myself to the line like a barnacle, so I must proselytize everyone into joining me in pushing the line ever higher up"
These people have no understanding of what's happening, but they invent one completely divorced from any reality other than the reality them and their ilk have projected into thin air via clout.
It looks like mental illness and hoarding Mac Minis and it's distasteful to people who know better, especially since their nonsense is so overwhelmingly loud and noisy and starts to drown out any actual signal.
The negativity is driven by outrageous claims how AIs will replace programmers, or how english is the PL of the future. T
> if you can't see the value in this, I don't know what to tell you.
You could perhaps start by telling what value you see in this? And what this company does that someone can't easily do themselves while committing to GH?
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.
But that's not what is in the whole context. The whole context contains a lot of noise and false "thoughts". What the AI needs to do is to document the software project in an efficient manner without duplication. That's not what this tool is doing. I question the value in storing all the crap in git.
I wonder. How often will that context actually be that valuable vs just more bloat to fill up future API calls with to burn tokens.
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.
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
How does this differ from what Github Copilot does when writing its .github/copilot-instructions.md? That doesn't keep the transcript or prompts, but it does keep quite a bit of the context and a declarative state of the decisions/design considerations made so another AI bot can pickup and have enough context to understand the rationale. I'm also not really convinced that any AI agent wouldn't still parse the code to understand more about the context vs. just using the checkpoint.
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.
Didn’t Juicero get more than a $100M? Do you think they had a clear plan? How much did Rome get? Did they have a clear plan?
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.
And look where Docker Inc is now (which is one of the points some critics are making)
Sure, but long term business success aside, I’m sure most of the folks working at this company would die for a fraction of the adoption curve docker had.
I think this is neat; in fact, I orchestrated my AI agents to do something similar (keep a log of files touched and why). And I have agents refer to the work log as well when they are unclear on why something exists.
It's not 1:1 with checkpoints, but I find such things to be useful.
I'm trying it out now. If it works, I think it'd be great for my agentic workflows where I need to figure out why something was done a specific way.
I have a lot of concurrent agents working on things at the same time, so I'm not always sure why a piece of code is the way it is months later.
I've used it for a couple of hours. A few observations:
- It's nice to see conversation context alongside the change itself. - I wasn't able to see Claude Code utilise past commit context in understanding code. - It's a tad unclear (and possible unreliable) in what is called 'checkpointing'. - It mucked up my commit messages by replacing the first line with a sort of AI request title or similar.
Sadly, because of the last point (we use semantic release and git-cz) I've had to uninstall it.
This sounds like you're using the auto-commit strategy instead of the default manual-commit strategy. manual-commit does not automatically commit. It just adds a trailer to the git commit message to link the checkpoint to the commit.
I've found immense value in this, am already doing it with Pi(https://github.com/badlogic/pi-mono) and it's very easy to replicate
Do you mean the value in this specific tool, or in the concept? You don't need a dedicated tool to store agent session transcripts and link them to commits. This can be accomplished by a 10-line bash script.
I built out the same thing in my own custom software forge. Every single part of the collaborative development process is memoized.
And how are you using it now? Have you seen real value weeks or months on?
It's in active development in my free time. I've built various agent orchestration systems over the years for different reasons, ever since the GPT-3 API. I can tell you utility has continually risen, the models are just getting better, and late 2025 was an inflection point, which is why we're seeing all of these orchestration solutions pop up now.
I still have kinks to work out in mine but it's already usable for building software. Once I get to v1 I think it will provide enough value to be useful for me in particular. I don't have enough data to speak about months on yet, but if I think the experiment is a success then I will do a Show HN or something.
The gist is you can clone a repo or start a project from scratch, each engineering agent gets a worktree, you work with the manager agent and it dispatches and manages other agents. there are playbooks which agents contextually turn into specific tasks, each of which is tracked much like CI/CD. You can see all the tool calls, and all of the communication between both agents and humans.
The application model is ticket-based. Everything revolves around the all-holy ticket. It's like a prompt, but it becomes a foundation for tying together every bit of work related to the process of developing the feature. So you can see the progress of the ticket through the organization kanban style, or watch from a dashboard, or look at specific tickets.
There are multiple review steps where human review and intervention are required. Agents are able to escalate to humans whenever they think they need to. There is a permission system, where agents have to seek permissions from other agents or humans in a chain of command in order to do certain tasks. Everything is audited and memoized, allowing for extreme accountability and process refinement stages.
Additionally, every agent "belongs" to either another agent or a human, so there is always a human somewhere in the chain of command who is responsible and accountable for the actions of his agent team. This team includes the manager agent, engineering agents, test agents, QA agents, etc, each loaded with different context, motivations and tools to keep them on track and attempt to minimize the common failure modes I experience while working closely with these tools all day.
> This thread is extremely negative - if you can't see the value in this, I don't know what to tell you.
This sounds a lot like that line from Microsoft's AI CEO "not understanding the negativity towards AI". And Satya instructing us to not use the term "slop" any more. Yes we don't see value in taking a git primitive like "commit" and renaming it to "checkpoint". I wonder whether the branches going to be renamed to something like "parallel history" :)
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.
Claude Code captures this locally, not in version control alongside commits.
I wonder how difficult it would be for Claude Code to have such a feature in a future release.
>. This thread is extremely negative - if you can't see the value in this, I don't know what to tell you.
It's almost a meme: whenever a commercial product is criticized on HN, a prominent thread is started with a classic tone-policing "why are you guys so negative".
(Well, we explained why: their moat is trivial to replicate.)
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.
How would this use any extra tokens? Just seems like it's serializing the existing context
I see the utility in this as an extension to git / source control. But how do VCs make money of it?
Is that sarcasm ? Dump a bunch of JSON from llm proxy and commit it ? Sounds like billion dollar secret sauce to me.
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.
[flagged]
Please don't use quotation marks to make it look like you're quoting someone when you aren't. That's an internet snark trope and we're trying to avoid those on HN.
https://news.ycombinator.com/newsguidelines.html
Look it’s obvious at this point to anyone who is actually using the tools.
We can articulate it but why should we bother when it’s so obvious.
We are at an inflection point where discussion about this, even on HN, is useless until the people in the conversation are on a similar level again. Until then we have a very large gap in a bimodal distribution, and it’s fruitless to talk to the other population.
Not really, because those details aren't actually relevant to code archaeology.
You could have someone collect and analyze a bunch of them, to look for patterns and try to improve your shared .md files, but that's about it
[flagged]
I think if you add some more emotional vitriolic language to your reply you’ll finally, finally get your point across. /s
[flagged]
I will never use this platform. i didn't even click into it. pathetically, i did click to view comments
But I think commenting on someone's bio is the kinda harshness you only do in the moment. the kinda thing I'd approach differently in hindsight (one that isn't an attempt to be cruel)
Harsher than the OP who is ridiculing everybody who criticizes the product being presented here in this thread?
Yes, much harsher
> This thread is extremely negative - if you can't see the value in this, I don't know what to tell you.
Just an opinion and not ridiculing or attacking someone specifically
amongst all the threads, it appears they are quite outnumbered lol
I have an agent write a file with this template each run:
```markdown # Run NNNN
## First Impressions [What state is the project in? What did the last agent leave?]
## Plan [What will you work on this iteration? Why?]
## Work Log [Fill this in as you work]
## Discoveries [What did you learn? What surprised you? What should the next agent know?]
## Summary [Fill this in before committing] ```
This is surprisingly effective and lets agents easily continue in progress work and understand past decisions.
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…
> Spec-driven development is becoming the primary driver of code generation.
This sounds like my current "phase" of AI coding. I have had so many project ideas for years that I can just spec out, everything I've thought about, all the little ideas and details, things I only had time to think about, never implement. I then feed it to Claude, and watch it meet my every specification, I can then test it, note any bugs, recompile and re-test. I can review the code, as you would a Junior you're mentoring, and have it rewrite it in a specific pattern.
Funnily enough, I love Beads, but did not like that it uses git hooks for the DB, and I can't tie tickets back to ticketing systems, so I've been building my own alternative, mine just syncs to and from github issues. I think this is probably overkill for whats been a solved thing: ticketing systems.
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".
If you are using claude, in your project's `.claude/settings.json` you can add something like:
```
```Just update it to iterate over your file. It should be a little easier to manage than git hooks and can hammer in testing.
That's hilarious, I called it gates too for my reimplementation of Beads. Still working on it a bit, but this is the one I built out a month back, got it into git a week ago.
For me a gate is: a dependency that must pass before a task is closed. It could be human verification, unit testing, or even "can I curl this?" "can I build this?" and gates can be re-used, but every task MUST have one gate.
My issue with git hooks integration at that level is and I know this sounds crazy, but not everyone is using git. I run into legacy projects, or maybe its still greenfield as heck, and all you have is a POC zip file your manager emailed you for whatever awful reason. I like my tooling to be agnostic to models and external tooling so it can easily integrate everywhere.
Yours sounds pretty awesome for what its worth, just not for me, wish you the best of luck.
https://github.com/Giancarlos/GuardRails
This is built in to Claude Code, when you're in plan mode it makes a task MD file, even giving it a random name and storing it in your .claude folder.
I'm confused how this is any different to the pretty standard agentic coding workflow?
that's similar to the workflow i built, inspired by Recursive Language Models: https://github.com/doubleuuser/rlm-workflow
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
Nice, I'll check yours out after work, looks pretty polished.
I’m testing this as well, but I’ve no idea people are getting good results out of Claude. What a waste of money… it’s incredible. It will get stuck on everything: basic string substitution, trying to install Python dependencies in a Node project, finding usages of something it’s trying to edit, and on and on.
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.
I started off with the original beads and it was definitely a nightmare. However I would recommend using https://github.com/Dicklesworthstone/beads_rust - it's a much simpler implementation of the same concept, without all the random extra stuff thrown on to support Gas Town.
`br` is still massively larger than necessary for the feature set.
I didn't mention above but I made https://github.com/wedow/ticket as my beads replacement back at the end of December.
I have zero reach compared to Jeff there so I'm considering `ticket` to be a smash hit at this point ;)
> Checkpoints run as a Git-aware CLI. On every commit generated by an agent, it writes a structured checkpoint object and associates it with the commit SHA. The code stays exactly the same, we just add context as first-class metadata. When you push your commit, Checkpoints also pushes this metadata to a separate branch (entire/checkpoints/v1), giving you a complete, append-only audit log inside your repository. As a result, every change can now be traced back not only to a diff, but to the reasoning that produced it.
The context for every single turn could in theory be nearly 1MB. Since this context is being stored in the repo and constantly changing, after a thousand turns, won't it make just doing a "git checkout" start to be really heavy?
For example, codex-cli stores every single context for a given session in a jsonl file (in .codex). I've easily got that file to hit 4 GB in size, just working for a few days; amusingly, codex-cli would then take many GB of RAM at startup. I ended up writing a script that trims the jsonl history automatically periodically. The latest codex-cli has an optional sqlite store for context state.
My guess is that by "context", Checkpoints doesn't actually mean the contents of the context window, but just distilled reasoning traces, which are more manageable... but still can be pretty large.
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.
MCP server with RAG to feed it back to agents when they are working on a piece of code, and bob's your uncle
That sounds like word salad, not a clearly articulated solution to a well-understood customer problem.
In simpler terms - they create an MCP server, essentially an API that the coding agent can call, that can fill in context about previous decisions done by the coding agent earlier in development. Agent equivalent of asking someone who's been working there longer "why is this this way".
This means that the agent will can have context of previous decisions, something that they currently struggle with as they are always starting from a blank slate.
> 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.
It's sad to see that ex-GitHub CEO didn't make enough money to just kick-start his company, but needs external money which will later on dictate how the company works or will sell users and the product for the next exit..
So.. yea. Ignore and move on.
Why burn his own money when he can get VC money instead?
If he believes in the product he could have kept 100% of his company.
He kept 80%. The other 20% is owned by 8 different VCs. Seems like he's still in control. There's value in using other people's money instead of your own because it might make him less emotionally risk-averse in how he manages it.
100% of something without any measurable adoption or scale can suck.
Most of the time it's not about the money VCs send into it but the credibility that this brings. It looks a lot more mature when your idea is backed by a distribution of wealthy people.
The point is more - it's primary goal is not to enable developers to do more and better, it's primary goal is to _maximize shareholder value_. Important thing to keep in mind.
The world's richest man solicited investors and other people's money to buy Twitter.
https://en.wikipedia.org/wiki/Acquisition_of_Twitter_by_Elon...
I think that's just how rich people play the game. Why use your own money when you can use other people's money?
Maybe he prefers to burn someone else’s money.
You know even Google looked for external investors for Waymo, right?
Yeah, Google. That company with more than $100B in cash. Even they know that it's better to burn someone else's money.
Certain amount of risk per initiative.
Diversify.
> The game has changed. The system is cracking.
Just say what your thing does. Or, better yet, show it to me in under 60 seconds.
Web sites are the new banner ads and headings like that are the new `<blink>`.
Exactly ... tired by all the marketing hyperbole talk. Just show what your product does in a simple example / showcase. If it's good, people will like it. You can save yourself a lot of text copy and user time that way.
They'll learn soon enough that selling to developers necessitates speaking clearly.
Dohmke never spoke clearly to developers when he was GitHub's CEO.
A CEO is never speaking to developers, he's speaking to other CEOs.
CEOs have many audiences; great CEOs communicate capably with each.
FWIW it's not entirely clear to me who Entire's long-term customer is, but the (interesting!) CLI that shipped today is very much for developers who are busy building with agents.
They will sell to their managers
No. With this kind of bullshit they plan to try to sell to C-levels and board members.
Edit: Actually it may just be aimed at investors. Who cares about having a product?
> Actually it may just be aimed at investors
The fact that the first image you see has "$60M seed" in big text, I have to agree, this does not feel aimed at devs.
The problem is that when it comes to (commercial) developer tools and services, everyone can/wants to be everything, so why let a simple statement or a showcase limit you? "Hey, we are a container scanning service... But we can also be a container registry too, a CI, a KeyValue store, an agent sandbox provider, git hosting? We can do quick dev deployments/preview too. Want a private npm registry? Automated pull request reviews? Code Signing service? We are working on a new text editor btw"
I feel like these types of pages are less geared towards actual users of the product and more towards the investors who love the vague and flowery language. We're no longer in a world where the path to profitability was the objective goal anyway, it makes sense to me that the marketing of software is becoming decreasingly detached from reality..
It's almost like an extension of the "if you're not paying for the product, you are the product" idea. If you're assessing a tool like this and the marketing isn't even trying to communicate to you, the user, what the product does, aren't you also kind of "the product" in this case too?
But what if my product is just an attempt to make a cushy exit during the AI bubble?
> Web sites are the new banner ads and headings like that are the new `<blink>`.
It's been like this since the Dotcom era
Or did you forget that you can do anything at zombo.com?
It appears to be rather slow today, but here's a Wiki link for the uninitiated- https://en.wikipedia.org/wiki/Zombo.com
The domain expired a few days ago and was purchased by someone else and then changed. There's a recreation of the original here https://html5zombo.com/
That's the saddest news I've heard this year.
It's still around, but has been redesigned and it's under "new management". Further proof that the internet is dying.
Awful news to hear. May its limitless frontiers rest in peace.
Wait really?!? I’m surprised at how much that saddens me. What is the point of the internet without zombo com
Seems they install a Git hook or something that executes on commit and saves your chatbot logs associated with the commit hash. This is expected to somehow improve on the issue that people are synthesising much more code than they could read and understand, and make it easier to pass along a bigger context next time you query your chatbots, supposedly to stop them from repeating "mistakes" that have already wasted your time.
Its like a modern day redux of zombo com.
That’s a bit insulting to zombo.com.
AI is everything at zombo.com.
Everything is AI at zombo.com.
I couldn’t figure out what they were doing in the first few screens of scrolling. Moved on.
It’s also a completely meaningless headline. It could be the beginning of just about any Medium post, corporate blog, or cyberpunk Steam game.
You need to use AI to summarize the point of articles about AI products
Same, then I pasted URL to Claude and asked it to explain the product to me: Blocked. Irony is palpable.
They also seem bothered by color photography in 2026. All style, no substance.
What it does? Imagine a multi line commit message.
Yes yes a Dropbox comment. But the problem here is 1 million people are doing the same thing. For this to be worth 60M seed I suspect they need to do something more than you can achieve by messing around locally."
"Claude build me a script in bash to implement a Ralph loop with a KV store tied to my git commits for agent memory."
It is not the system that is on crack ...
This feels interesting because the real problem with AI generated code isn't that it is of better or worse quality than code written by a human, it's that we humans need to audit both types of code. And this platform feels like it addresses this in a novel and traditional way. I like it.
Checkpoints are not granular enough. You have to grab a work summary before the context window closes, not when you decide to commit. I have thousands of work summaries from one project alone. I use them to traverse sessions.
This is the agent that does the work: https://github.com/ChicagoDave/devarch/blob/main/docs/.claud...
My success with Claude Code is directly related to this agent and its output.
interesting. Do you have an example of what exactly it outputs and how you store that? how do you use the outputs? As a pointer to a new agent with fresh context to get them up to speed?
This is the current context docs in my text adventure authoring platform Sharpee:
https://github.com/ChicagoDave/sharpee/tree/main/docs/contex...
Note I archive these to a different non-repo folder regularly. It's fun to tell Claude to go through them like a RAG implementation and note the progress of my development over time, which I update semi-regularly at: https://david.cornelson.net/sharpee-status-20260109.html
Now updated to https://david.cornelson.net/sharpee-status-20260211.html
60 million dollar idea and you’re giving it away for free!
Yes. None of this early stuff should be monetized and that Entire business model is all about monetizing something that doesn't need it.
I have hooks in Claude to auto-generate the work summary and read the last work summary on start. Now if I could only get Claude to quit/restart on its own or have it thoroughly flush its resources (even Anthropic says restarting is better), we'd be getting somewhere. I do wish there were automatic hooks that fire all the time (like a heart monitor) where I could query "if context is below 15%" do this: stop all work, write work summary, commit and push all changes, release all resources, read last work summary, continue the work.
That would be awesome.
If someone from Entire wants to pay me for my GenAI experience, give me a ring!
Ignoring the VC economics and awful name, I won’t be as pessimistic as everyone. I see the vision.
That said, nobody knows what the AI future looks like. Entire’s entire thesis is a solution for something we don’t even know we need. It’s a massive bet and uphill battle. Traditionally, dev tool success stories come from grassroots projects of developers solving their own problems and not massive VC funded efforts that tell you what you need to do.
I feel like it says a lot if this is the not pessimistic take.
My pessimism is mostly rooted in the VC economics of it all. The vision is great, but its a busy space and there's no actual product or business. They basically wrote the guy a check to build the spaceship in space.
I actually feel like the LLM-driven AI future is relatively forseeable. It's only if we get a new, cooler architecture that we'll see a fundamental change to what we've kind of known for a while now
And yet, this is precisely what seed bets are about. You have to try it in order to know whether there is a "there" there.
$1.5M seed bets, maybe. not $60M though
Actually interesting, but how's that different from just putting your learning / decision context into the normal commit text (body) ? An LLM can search that too, and doesn't require a new cli tool.
EDIT: Or just keep a proper (technical) changelog.txt file in the repo. A lot of the "agentic/LLM engineering frameworks" boil down to best approaches and proper standards the industry should have been following decades ago.
After I have an ai dona task, I ask the next one to look at that plan and git diff and so ble check validate
I don't see the need for a full platform that is separate from where my code already lives. If I'm migrating away, it's to something like tangled, not another VC funded company
This is a good idea but I feel like you could get something similar by just adding an instruction for the agent to summarize the context for the commit into a .context/commit/<sha> file as a git hook.
Or git notes.
Commit hook > Background agent summarizes (in a data structure) the work that went into the commit > saves to a note
Built similar (with a better name) a week ago at a hackathon: https://github.com/eqtylab/y
Exactly. I don't want to wade through a whole session log just to get to reasoning, and more importantly, I don't want to taint my current agent context with a bunch of old context.
Context management is still an important human skill in working with an agent, and this makes it harder.
[dead]
Agents can save their reasoning into markdown files, and commit those files to Git. Are "Checkpoints" just a marketing term for that, or there's more to it?
Claude Code already does this, you can access it with /resume, /rewind and /fork. I'd imagine building a version that saves in the repo instead of in the home folder would take very minimal effort.
This is about doing it seamlessly and flawlessly then sharing it across a team.
So using something like the compound engineering plugin and committing its "brainstorms", plans, and "solutions"?
No, it's not. I can't get leadership's buyin on a Claude Plugin.
I think the moat depends on how long it takes for an agent to ingest the entire commit history and product documentation into context on the fly. At the rate models are improving, seeing the reasoning chain of an outdated model that led to a commit that warrants post-hoc review (likely becuase of a bug) would mainly be useful for root cause analysis more than for insight into what to do next... but chances are the newer model would have been able to infer it from local context anyway.
It also creates a challenge with respect with the embedding model chosen and how future proof it turns out to be.
I landed on a similar vision last year. The more I thought about it, the moat felt fragile. GitHub or GitLab could build the same capabilities and become a natural extension of what teams already use. That said, it addresses a real problem, and the SDLC needs to evolve.
The product isn't the software, it's your data. The VC's didn't give Dohmke $60m to build a new frontend for Git/ GitHub... They're going to capture your conversations and code with AI (The outcomes) and use that to train better models which they'll rent back at you.
100%, and many developers are gonna fall for it. I’m off GitHub because I don’t think every corporation under the sun should profit off my work.
60 million SEED round? This is really a thing now?
Hey, they said AI was 100x right?
Take a look at the 500M seed round next :)
[dead]
Hmm the whole point of checkpoints seems to be to reduce token waste by saving repeat thinking work. But wouldn't trying to pull N checkpoints into context of the N+1 task be MUCH more expensive? It's at odds with the current practice of clearing context regularly to save on input tokens. Even subagents (which I think are the real superpower that Claude Code has over Gemini CLI for now) by their nature get spawned with fresh near-empty context.
Token costs aside, arguably fresh context is also better at problem solving. When it was just me coding by hand, I didn't save all my intermediate thinking work anywhere: instead thinking afresh when a similar problem came up later helped in coming up with better solutions. I did occasionally save my thinking in design docs, but the equivalent to that is CLAUDE.md and similar human-reviewed markdown saved at explicit -umm- checkpoints.
Yes I also don't see how having persistent context would help. For one, I don't want to read the slop the AI produced while it wrote the code. It doesn't have intent or thinking, it's a completion machine. The code is the artifact that matters, not the thousands of lines of "Your absolutely right --- I was wrong to ..."
Also, sometimes it gets something very wrong. I don't want to then poison every subsequent sessions with the wrong thing it learned. This has been a major issue for me at $WORK with AGENTS.md files that my colleagues write: they make my agent coding much worse so I need to manually delete them often.
>CLI to tie agent context into Git on every push.
Is this the product? I don't want to jump on the detractor wagon, but I read the post and watched the video, and all I gathered is that it dumps the context into the commit. I already do this.
> I already do this.
Hows your ability to get an enterprise to mandate their 5000 employees to use it? That's what most of these types of rounds are about.
This doesn't appear to address that concern.
I guess if I had to do it, I'd reject pushes without the requisite commit to entire/checkpoints/v1. I think their storage strategy is a bit clunky for that, but it can be done. I might look to do something more like the way jujutsu colocates its metadata. I don't think this particular implementation detail makes too much of a difference, though. I got along just fine in a regulated environment by setting a policy and enforcing it before git existed. Ideally, we'd do things for a good reason, and if you can't get along in that world, then it's probably not the right job for you. Sometimes you've got to get the change controls in order before we can mainline your contributions because we have to sustain audits. I don't think this is about forcing people to do something that they otherwise wouldn't do if you told them that it's a requirement of the job.
This does not address it one bit. Everyone has to install it, authorize themselves with said GH repo etc.
And since you mentioned "enterprise", they won't be able to use it if they do not use GH, and a lot of enterprise cropos use azure devops.
Also there is no user management etc, if anything this is ANTI-enterprise.
100%. Day one is to ship the basic capability, which many of us have already vibe-coded... Day two is all the enterprise stuff to make big companies trust AI coding more. That could unlock a lot of revenue. This isn't random at all.
Uuh easy fire them all and replace with said agents
Isnt this overloading git commits too much ? Like 50kb per commit message
Git is totally fine keeping a few extra text files. These are ephemeral anyway. The working sessions just get squashed down and eliminated by the time I've got something worth saving anyway. At that point, I might keep a overview file around describing what the change does and how it was implemented.
(I will give the agent boom a bit of credit: I write a lot more documentation now, because it's essentially instruction and initial instruction to anything else that works on it. That's a total inversion, and I think it's good.)
The bigger problem is, like others have said, there's no one true flow. I use different agents for different things. I might summarize a lot of reasoning with a cheap model to create a design document, or use a higher reasoning model to sanity check a plan, whatever. It's a lot like programming in English. I don't want my tool to be prescriptive and imposing its technical restrictions on me.
All of that aside: it's impossible that this tool raised $60 million. The problem with this post is that it's supposed to be a hype post about changing the game "entirely" but it doesn't give us a glimpse into whatever we're supposed to by hyped about.
the git commits message description never go away though, unless you're editing the git with BFG cleaner
1. Commit messages go away if you remove the commit, but
2. Don't put it in the message. Put it in files.
Same thought. If anything I'm usually trying to find ways to reduce how much context is carried over.
I have it (claude, codex) summarise what we've discussed about a design, big change, put it in an MD file and then I correct it, have it re-read it and then do the change.
Then later if it goes off piste in another session tell it to re-read the ADDs for x, y and z.
If someone could make that process less clunky, that would be great. However it's very much not just funnel every turd uttered in the prompt onto a git branch and trying a chug the lot down every session.
what about using git notes to stash the summaries? (https://git-scm.com/docs/git-notes)
Very similar for me. I have a plans folder in my root where I store the plans while they're either under improvement or under implementation. Once they're done they're moved into the plans/old folder. So far it's worked great. It's a couple of manual steps extra but very helpful record.
Pretty much the same thing. I don't find it to be a burden. Regarding the product, I'm willing to believe I just don't see big picture, but without some peek at the magic, I don't know how much easier this could really be.
[dead]
[flagged]
Huh, the checkpoint primitive is something that I've been thinking about for a while, excited to see how it's implemented in the CLI. Git-compatible structures seem to be a pretty big pull whenever they're talking about context management.
I'm not making a judgement on the product but why is everything about selling shovels? I want to see "real" software and new innovative ideas that are developed and maintained using AI and not just shovels 'advertised' on HN every week.
Show me the next blockchain or noSQL, or git!
Everything is "I took a prompt and stapled it to another prompt and added <insert existing OSS> framework".. and then. holds hand out "MONEY PLEASE!"
Feature plans generated by agents are often transient documents that fall away once the plan is executed. Ideally, that artifact would be preserved alongside the implementation.
My experience is that Cursor's reliance on VS Code's clunky panel-based UI and jack-of-all-trades harness is holding it back. Likewise, Claude Code shoe-horning a GUI into a TUI and perma-binding to a single model family is not the ideal end-state.
The VC play here? The git context CLI thing is a foundational step that lays the groundwork for a full IDE/workflow tool, I guess.
Why do you want to preserve that artifact?
If you don't have a record of questions asked/answered and rationale for decisions taken, I've noticed it's easy for subsequent feature plans to clash. Maintaining a line of consistency across each feature plan is a good thing.
I think thats what docs/comments are for, ask your agent to add/maintain them
No functional difference whatsoever. Literally the exact same solution, but somehow dressed up to be contrarian.
Checkpoints sounds like an interesting idea, and one I think we'll benefit from if they can make it useful.
I tried a similar(-ish) thing last year at https://github.com/imjasonh/cnotes (a Claude hook to write conversations to git notes) but ended up not getting much out of it. Making it integrated into the experience would have helped, I had a chrome extension to display it in the GitHub UI but even then just stopped using it eventually.
Ah you were 7mo ahead of me doing the same and also coming to a similar conclusion. The idea holds value but in practice it isnt felt.
https://github.com/eqtylab/y
What are they actually “checkpointing”? Git already “checkpoints” your code and they can’t time travel your LLM conversation.
I like the concept, but it seems like an obvious extension of where Anthropic is building with Tasks and Memory. What’s the moat? Cross-agent compatibility?
disclosure: i run a startup that will most likely be competitive in the future.
I welcome more innovation in the code forge space but if you’re looking for an oss alternative just for tracking agent sessions with your commits you should checkout agentblame
https://github.com/mesa-dot-dev/agentblame
Entire CEO here. We are going to be building in the open and full stack open source, but great to see alternatives.
Did you have to choose an adjective to name your product. Now it’s going to be very confusing for search engines and LLms. “Tell me more about entire.” “Entire what?” “You know, that entire thing.”
Another of your competitors here. It makes me giggle that we're going after the entire developer experience while Entire is only looking at a small corner of it.
Time will tell how small that corner is. ;)
Certainly! But just to confirm, you aren't making an IDE or building a version control system to replace Git, are you? While money means you need not fear me, the scale of my vision means that I don't fear you either.
Oh I don't think I need this if all of my commits are AI!
> When you push your commit, Checkpoints also pushes this metadata to a separate branch (entire/checkpoints/v1)
For Claude Code, this is literally a JSONL file in .claude/projects/[path with - instead of /]/[uuid].jsonl... You can trivially have Claude Code write a commit hook to do this for you if you find it useful.
I'm sure their vision is wider than that, but they will need to iterate fast for this not to be made obsolete before they can even release something.
FWIW, I had an agent adding archiving of the JSONL for changesets linked to the work they're doing right as I started looking at this article, as when you start automating a non-interactive agent flow it's such an obviously necessary step to be able to retrospectively improve the workflows.
How do you handle the retreival aspect? So you have this set up and now what?
>FWIW, I had an agent adding archiving of the JSONL for changesets linked to the work they're doing
Would love to know more! Sounds interesting.
I'm taking a very crude approach for now. My "improvement agent" has a few distinct stages: A goals extraction step that explores the repository, with some pointers to specific files that is consider authoritative as to the users intent, and then builds out files in docs/goals. That then feeds into a plan ideation stage that results in directories for plans in docs/plans. That directory has the plan itself, and logs of revisions etc. So for now I'm just dumping snapshots of those jsonl line files in there.
Putting it in a branch so it doesn't pollute your checked out copy may well be a good idea in the longer run. For now, I keep all the plans available, as I then have a review stage that reviews all the plans, and writes things like "the user got increasingly exasperated as the agent kept ignorning direction" :D and helps propose improvements to the tool and workflow to reduce the number of those exasperated movements...
I'm thinking of packaging it up and open-sourcing it. It's all very experimental and likely to totally change every day for now, but I find it helpful. It's built me a personal dashboard, and keeps adding stuff to it with relatively minimal direction beyond "spying" on my notes and journal at this point. At one point a plan specifically called me out for procrastinating and planned for how to "work around" that with tooling (I wish it'd succeed at that).
There's nothing really fancy here, just feedback loops that ensures the wild claims the agents sometimes will make are tested and rejected.
To the original JSONL bit, the uuid you need to look it up is also the UUID you need to call "claude --resume [uuid]", so extracting it also allows for e.g. having the verification agent (that checks if the implementation agent was truthful when ticking off the quality gates - spoiler: it very often isn't) feed its report back into the original implementation conversation if rejected, instead of having the implementation agent "start over" without the full context. I haven't tested that yet, but I'm hopeful.
Though even if you don't have it restart, you can point it to the snapshot of the previous conversation as a source of additional info, as another option.
That sounds incredibly interesting and helpful. You should pack it up and open source it. You might even get $60 million. I'd be super interested in seeing it. I love that idea about the UUID. I've been experimenting with that myself. I'd be interested in working on this with you if you wanted to open source it.
That's why several VC-funded AI companies are deliberately vague about what they are doing.
That is charitable of you. The alternative viewpoint is that they are vague about it because they have no idea what they are doing.
I'm sure they have a vision of something but I also think the moat is narrow here. A lot of what these companies thinks will be "special sauce" will be unnecessary because the frontier models are advancing 6 months from now, and survival at that point will come down to extremely proficient execution to manage to stay ahead.
(And most of these companies will not be good enough at that)
I don't understand how this is different from giving an agent access to github logs? The landing page is terrible at explaining what it does.I guess they are just storing context in git aswell?
So is this just a few context.md files that you tell the agent to update as you work and then push it when you are done???
All AI landing pages are so confusing, maybe because they are AI-built as well...
I had a similar, admitted poorly thought out idea a few months back.
I wanted to more or less build Jira for agents and track the context there.
If I had to guess 60 million is just enough to build the POC out. I don't see how this can compete though, Open AI or Anthro could easily spin up a competitor internally.
You don't need to build anything. Just tell the agent to write tickets into .md files in a folder and move them to a closed foler as you go along. I've been using Claude Code with the Max plan nonstop essentially every day since last July and since then I've come to realize that the newer people are the more things they think they need to add to CC to get it work well.
Eventually you'll find a way that works for you that needs none of it, and if any piece of all the extras IS ever helpful, Anthropic adds it themselves within a month or two.
I'm thinking a customized LLM would write notes in its own hyper compressed language which would allow it to be much much more efficient.
For debugging you could translate it out to English, but if these agents can do stuff without humans in the loop, why do they need to take notes in English?
I can't imagine creating this without hundreds of millions if not billions. I think the future is specialized models
They're literally trained on natural language to output natural language. You would need to create the hyper compressed language first, convert all of your training data to that, and then train the models with that. But token efficiency per word already does vary between different languages, with Chinese being like 30%-40% more efficient than English last I heard
Doesn't this mean the Chinese models have a significant advantage ?
This isn't my domain, but say you had a massive budget, wouldn't a special LLM "thinking" language make sense ?
Isn't that basically what things like this are for, open source, free.... https://github.com/steveyegge/beads
Shouldn't this tool be agnostic to the models? Seems like a 3rd party is the way to go.
In what world do you need $60M to build a POC of whatever this is supposed to be?
> If I had to guess 60 million is just enough to build the POC out.
You're kidding.
My first thought that it was made for companies which tie "AI usage" to performance evaluation.
There is also Git AI: https://github.com/git-ai-project/git-ai https://usegitai.com/
love the shout but git-ai is decidedly not trying to replace the SCMs. there are teams building code review tools (commercial and internal) on top of the standard and I don't think it'll be long before GitHub, GitLab and the usual suspects start supporting it since folks the community have already been hacking it into Chrome extensions - this one got play on HN last week https://news.ycombinator.com/item?id=46871473
yep i know it's not meant to be an SCM tool but I thought it was somewhat related to what they're doing right now:
"Entire CLI hooks into your git workflow to capture AI agent sessions on every push."
Which is capturing the LLM convo along with the code (I could be wrong ofc)
I miss the good old days:
https://news.ycombinator.com/item?id=338286
The lack of explanation of what it is and does is a tell of what gullible audience they are seeking.
Tech marketing has become a lot like dating, no technical explanation and intellectual honesty, just word words words and unreasonable expectations.
People usually cannot be honest in their romantic affairs, and here it is the same. Nobody can state: we just want to be between you and whatever you want to accomplish, rent seeking forever!
Will they ever care to elaborate HOW things works and the rationale behind stating this provides any benefit whatsoever? Perhaps this is not intended for those type of humans that care about understanding and logic?
No, because the goal isn't to make things work. The goal is to make money by appearing to make things work. People who actually know don't tend to take ridiculous sums of money just to go tinker for a few years—they just build the damn thing and move on. The game here is perception and money—not necessarily competent engineering or legible products.
I think it's extremely value what Thomas is doing with Checkpoints, I have this built in on autohand code cli that allows you to share with others your session /share https://autohand.link/s/ah-23wbbq4v2r5vt86684hg-1768476838
You can see the turns, tools called, outputs, changes. Similar to what he's trying to achieve.
This feels a bit like when some Hubbers broke off to work on PlanetScale, except without the massively successful, proven-to-be-scalable open source tool to build off (Vitess).
If you're approaching this problem-space from the ground up, there are just so many fundamental problems to solve that it seems to me that no amount of money or quality of team can increase your likelihood of arriving at enough right answers to ensure success. Pulling off something like this vision in the current red-ocean market would require dozens of brilliant ideas and hundreds of correct bets.
For a solo developer this is pretty useless. For a team where everyone uses same coding tool this might be useful.
I am afraid however that with these tools Claude Code will just copy this in 3 months and have it as standard functionality within itself as a plugin.
Also I find it ironic that this domain is blocking all AI tools to access it, I tried to ask AI to explain what is the product and it is blocking Claude/GPT access to the website.
I shall give the benefit of a doubt given they are "building in the open". I feel my current setup already does all this though, so I struggle to see the point
It’s funny. The whole “review intent", "learning" from past mistakes, etc, is exactly what my current set up does too. For free. Using .md files said agents generate as they go.
> Checkpoints are a new primitive that automatically captures agent context as first-class, versioned data in Git. When you commit code generated by an agent, Checkpoints capture the full session alongside the commit: the transcript, prompts, files touched, token usage, tool calls and more.
Whether or not useful for agent collaboration, the data here will be more valuable than gold for doing RL training later on.
Just have a data lake with annotated agent sessions and tool blobs (you should already be keeping this stuff for evals), then give your agent the ability to query it. No need for a special platform, or SaaS.
As for SDLC, you can do some good automations if you're very opinionated, but people have diverse tastes in the way they want to work, so it becomes a market selection thing.
This is the way
> Git repositories were never extended to version everything developers build with in the AI era. [... more fatalistic verbiage ...] A system that cannot be retrofitted for what's ahead.
Two paragraph later:
> Entire will be based on three key components: a git-compatible database [...]
So which one is it?
I hacked together something similar to the concept they describe a few months ago (https://github.com/btucker/agentgit) and then ended up not actually finding it that useful and abandoning it.
I feel like the value would be in analyzing those rich traces with another agent to extract (failure) patterns and learnings, as part of a flywheel setup. As a human I would rarely if ever want to look at this -- I don't even have time to look at the final code itself!
> value would be in analyzing those rich traces with another agent to extract (failure) patterns and learnings
Claude Code supports hooks. This allows me to run an agent skill at the end of every agent execution to automatically determine if there were any lessons worth learning from the last session. If there were. new agent skills are automatically created or existing ones automatically updated as apporpriate.
Yes, I've done the same. But the issue is that the agent tends to learn too many lessons, or to overfit those lessons to that single session. I think the benefit of a tool like this is that you can give that agent a wider view when formulating recommendations.
Completely agree. But I wonder how much of that is just accomplished with well placed code comments that explain the why for future agent interactions to prevent them from misunderstanding. I have something like this in my AGENTS.md.
Try running `/insights` with Claude Code.
There is no such command, according to the docs [0]. /s
I continue to find it painfully ironic that the Claude Code team is unable to leverage their deep expertise and unlimited token budget to keep the docs even close to up-to-date automatically. Either that or they have decided accurate docs aren't important.
[0] https://code.claude.com/docs/en/interactive-mode#built-in-co...
Its a shame Pierre shut down. Wish they could have made it work. Github but made by Linear would be a dream.
Linear will have something for you soon – https://linear.app/reviews
Pierre didn't shutdown, they said they just paused signups on the code review app to focus on the code storage service.
Productizing the building blocks of the platform seems like the smart play in today's environment honestly.
Sure but I dont want to build my own Github I just want to use a beautiful and faster alternative
We’re shooting for this with Tangled (https://tangled.org). :)
I would argue the largest developer tools/services acquisition in recent history was GitHub (assuming you don't count RedHat in that category). GitHub was primarily an acquisition focused on acquiring the network of developers, based on the trust and cachet GitHub had earned, with the intent to upsell (land and expand) the developers at large Enterprise companies on downstream workflows and tools.
If I were an employee looking to join Entire, or a developer evaluating the durability of Entire for my needs over the long-term, I'd ask things like —
- What's the terminal value of a DevTool in the AI era? Is it closer to a standard 10x ARR? or maybe 100x...perhaps 1000x?
- Is there value in the asset attributable to the network? If so, is it defensible? What is the likelihood protocols emerge that simply disintermediate the network moat of a AI agent memory company like Entire?
- What kind of AI data are developers willing to silo with a single vendor? What kind of controls do Enterprises expect of an AI agent memory system? Can Entire reasonably provide them to grow in the next 12-24 months?
- As a potential employee...if you join a company with a $60M seed funding and 19 employees, what is the ARR they need to achieve based on the first product in market in roughly ~12 months? $6M...$12M...20M? Is there a DevTools company that's ever done that!? What is the thesis for "this time is different"? Getting developers to pay for things is tough 'doncha know?
Only then can you ask basic technical diligence questions —
- Is Git a system that can scale to be the memory system and handle the kind of tasks that AI agents are expected handle?
- Are the infrastructure costs for these early platform decisions here reasonable over the long-term? Or do they just run out of money?
I wish them the best, and I hope employees get liquidity, and people take money off the table in a responsible way.
I did test it and use it and trashed it because there is very little value, actually none for me. These problems are easily being solved in other ways whoever has any experience with these tools. Getting $60M round for this stuff is ridiculous.
I'm interested to see if they will try to tackle the segregation of human vs AI code. The downside of agents is that they make too much changes to review, I prefer being able to track which changes I wrote or validated from the code the AI wrote.
For people trying to understand the product (so far), it seems that entire is essentially an implementation of the idea documented by http://agent-trace.dev.
I built a skill for this: https://github.com/doubleuuser/rlm-workflow
The readme is a bit more to the point.
I love this. Prompt engineering is a real skill, and learning by example is the best way to do it. Juniors being able to see how seniors actually did something is really powerful.
It doesn't seem to work if you use Claude plugins like feature-dev and commit-push-pr.
I tested it with multiple PRs and I see nothing in GH nor Entire dashboard.
> Cursor's Composer 2.0
There is no Composer 2.0. There is Cursor 2.0 and Composer 1.5.
Entire company as a protocol. Can GitHub implement this?
Imagine shipping a product, and a few weeks later, you see Thomas Dohmke raise $60M for almost the exact same idea.
Some weeks ago we launched this:
https://github.com/Legit-Control/monorepo/tree/main/examples...
The idea was simple: keep AI prompts, intents, and conversations alongside your code and commits — basically treating AI interaction as first-class development artifacts. everything just plain Git
We struggled to get momentum. Things happen.
Now, less than 24 hours ago, Thomas announced Entire.io:
“Entire CLI hooks into your git workflow to capture AI agent sessions on every push. Sessions are indexed alongside commits, a searchable record of how code was written.”
That’s… very, very close to what we tried to build.
Honestly, I love the vision and think this will matter a lot in the AI age. It’s validating to see someone with that reach betting big on it.
Best of luck to Thomas and the team behind Entire.
to be fair this is a pretty hot topic, that the work is shifting to the prompt/agent thread but then thrown out / not captured
greg brockman https://x.com/gdb/status/2019566641491963946
> 6. Work on basic infra [...] there's a lot of infrastructure that currently go around the tools, such as observability, tracking not just the committed code but the agent trajectories that led to them, and central management of the tools that agents are able to use.
peter steinberger (clawdbot/openclaw) https://newsletter.pragmaticengineer.com/p/the-creator-of-cl...
> Peter now views PRs as “prompt requests” and is more interested in seeing the prompts that generated code than the code itself
Absolutely, it's also cool to see that so much is happening here right now. Sometimes you need a bit of a network to get something like this off the ground. Building infrastructure is never easy.
There have been so many GitHub CEOs I was excited to find out which one.
Only four: Chris, Tom, Nat, and Thomas. Last one is me. ;)
PJ was technically CEO for awhile when they needed someone to do it
I don't want agent context tied to git commits. I just want infinite scroll in Claude Code and ability to search and review all my past conversations!
This sounds like Spark with extra steps. If I’m not mistaken, some version of Spark had a feature to jump on different iterations of your prompts.
New agent framework / platform every week now. It's crazy how fast things move...just when you get comfortable with an AI flow something new comes out...
Really hope that unlike GitHub it'll be open source
With a 60M seed? I doubt it.
Highly dubious of this.
I see zero reason for a person to care about the checkpoints.
And for agents, full sessions just needlessly fill context.
So not sure what is being solved by this.
Github but this time they're capitalizing on "agent traces". Alright. *Terrible* name btw.
Ironically, I was shortly contracting on PoC similar to this for ex github cofunder around this time last year.
> ... to Cursor's Composer 2.0 and more, ...
I couldn't find any references of Composer 2.0 anywhere. When did that come out?
1.5 released yesterday. probably just slop
- https://cursor.com/blog/composer-1-5
Fixed. It's Cursor 2.0 and Composer 1.5, mixed that up when editing the post last night.
I’m manually checking in Agent.md for every commit to improve the context window usage. Is that now automated?
you're doing what now?
What's the long-term or even short-term strategy to make money?
It's not like $60m in funding was given as charity.
General purpose agentic AI for enterprises since apparently that's the hot shit for 2026 now.
Sorry for not contributing to the discussion (as per the guidelines), but is it just me or this blog post reads a lot like LLM-filled mumble jumble? Seems like I could trim half of the words there and nothing would be lost.
Really struggling to figure out what this is at a glance. Buried in the text is this line which I think is the tl;dr:
"As a result, every change can now be traced back not only to a diff, but to the reasoning that produced it."
This is a good idea, but I just don't see how you build an entire platform around this. This feels like a feature that should be added to GitHub. Something to see in the existing PR workflow. Why do I want to go to a separate developer platform to look at this information?
I'm sure i'm missing something but can you not ask the llm to add the reasoning behind the commit in the comments as part of the general llm instructions?
Github sucks now, for one; people are looking for an alternative.
This is not an alternative to GitHub though. The code for this tool itself lives on GitHub!
https://github.com/entireio
Can someone please explain what is this?
I am already overloaded with information (generated by AI and humans) on my day to day job, why do I need this additional context, unless company I work for just wants to spend more money to store more slop?
How is it different than reversing it, given a PR -> generate prompt based on business context relevant to the repo or mentioned issues -> preserve it as part of PR description
I barely look at git commit history, why should I look for even higher cardinality data, in this case: WTF, are you doing, idiot, I said don't change the logic to make tests pass, I said properly write tests!
so I'm guessing now I can finally say "go fix the bug" and the future agents can run blame on old tracked prompts, find the thought process behind a line themselves, and fix the bug?
Not sure what it is or what it does.
Uses AI to summarize coding sessions tied to commits.
Commit hook > Background agent summarizes (in a data structure) the work that went into the commit.
Built similar (with a better name) a week ago at a hackathon: https://github.com/eqtylab/y
Which only reinforces someone just lit $60M on fire. It's trivial to do this and there are so many ways people do things, having the AI build custom for you is better than paying some VC funded platform to build something for the average
Not even pocket change compared to the billions of VC money burnt every month to keep the show running.
It extracts money from investors and allocates it to founders.
Entire.io, the name is on point considering it asks for access to my entire GitHub account.
But seriously, $300M valuation for a CLI tool that adds some metadata to Git commits. I don't know what to say.
Soooo.. It's like Git but on the intern... Er, with agents? On agents?
I don't see how we need a brand new paradigm just because LLMs evidently suck at sharing context in their Git commits. The rules for good commits still apply in The New Age. Git is still good enough, LLMs (i.e. their developer handlers) just need to leverage it.
Personally, I don't let LLMs commit directly. I git add -p and write my own commit messages -- with additional context where required -- because at the end of the day, I'm responsible for the code. If something's unclear or lacks context, it's my fault, not the robot's.
But I would like to see a better GitHub, so maybe they will end up there.
> The game has changed. The system is cracking.
No, it hasn’t. No, it isn’t.
Wait, since when is Dohmke out? I thought this was gonna be Nat.
I left August 11: https://github.blog/news-insights/company-news/goodbye-githu...
`/init` is good enough.
Model improvements will take care of the rest.
Shoulda launched a new chat protocol to replace discord.
I see the vision here. I think this is extremely needed.
I bet it will down/unstable 3/4 of the month.
I made something very similar, in my spare time, last week. I didn't need $60m for it.
https://github.com/re-cinq/claudit
What's amusing is that I specifically made a comedy license for it, because I thought trying to protect the IP of such a thing is madness in the AI-native era. Then within days I find out it's a massively funded startup!
https://github.com/re-cinq/ai-native-application-license/
I've got Claude Code adding Gemini and OpenCode support to my tool currently.
If you think about it, it makes sense.
Say what you want about LLM-assisted software development, the chances are high that it will stay, meaning a non-trivial part of code will be written by an LLM.
So is it better to have
or Obviously for that to work the LLM output has to be deterministic and a commit chain has to be pinpointed to a specific weight blob.check out https://codecast.sh !
can the agent not simply be instructed to save the "why" in the commit message?
New buzzwords in the big 2026
List of Github CEOs:
1. Tom Preston-Werner (Co-founder). 2008 – 2014 (Out for, eh... look it up)
2. Chris Wanstrath (Co-founder). 2014 – 2018
(2018: Acquisition by Microsoft: https://news.ycombinator.com/item?id=17227286)
3. Nat Friedman (Gnome/Ximian/Microsoft). 2018 – 2021
4. Thomas Dohmke (Founder of HockeyApp, some A/B testing thing, acquired by Microsoft in 2014). 2021 - 2025
There is no Github CEO now, it's just a team/org in Microsoft. (https://mrshu.github.io/github-statuses/)
Chris was also CEO from 2008 to 2012. Tom had 2012 to 2014.
Nat's company Xamarin was acquired by Microsoft in 2016.
HockeyApp wasn't A/B testing, but a platform for iPhone, Mac, Android, and Windows Phone developers to distribute their beta version (like what TestFlight is today to the App Store), collect crash reports (like what Sentry is today), user feedback, and basic analytics for developers.
Thanks for the fact check :).
The Ximian thing I wrote from obviously faulty memory (I now wonder if it was influenced by early 2000s Miguel's bonobo obsession), the rest from various google searches. Should have gone deeper.
No, I was actually correct.
https://en.wikipedia.org/wiki/Ximian
Ximian, Inc. (previously called Helix Code and originally named International Gnome Support) was an American company that developed, sold and supported application software for Linux and Unix based on the GNOME platform. It was founded by Miguel de Icaza and Nat Friedman in 1999 and was bought by Novell in 2003
...
Novell was in turn acquired by The Attachmate Group on 27 April 2011. In May 2011 The Attachmate Group laid off all its US staff working on Mono, which included De Icaza. He and Friedman then founded Xamarin on 16 May 2011, a new company to continue the development of Mono. On 24 February 2016, Microsoft announced that they had signed an agreement to acquire Xamarin.
Didn't say you were wrong. It was just missing the Xamarin step in the sequence of companies, and arguably Xamarin was the bigger milestone than Ximian.
[flagged]
"Don't be snarky."
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
Essentially all software is augmented with agentic development now, or if not, built with technology or on platforms that is
It's like complaining about the availability of the printing press because it proliferated tabloid production, while preferring beautifully hand-crafted tomes. It's reactively trendy to hate on it because of the vulgar production it enables and to elevate the artisanal extremes that escape its apparent influence
It's really not as integral as you make it sound. If I make one PR on a widely used open source tool with a small fix, is most software development augmented by me?
Outside of simply not being true, the sentiment of what you're saying isn't much different than:
"Essentially all software is augmented with Stack Overflow now, or if not, built with technology or on platforms that is."
Agentic development isn't a panacea nor as widespread as you claim. I'd wager that the vast majority of developers treat AI is a more specified search engine to point them in the direction they're looking for.
AI hallucination is still as massive problem. Can't tell you the number of times I've used agentic prompting with a top model that writes code for a package based on the wrong version number or flat out invents functionality that doesn't exist.
I just cannot fathom how people can say something like this today, agentic tools have now passed an inflection point. People want to point out the short comings and fully ignore that you can now make a fully functioning iPhone app in a day without knowing swift or front end development? That I can at my company do two projects simultaneously, both of them done in about 1/4 the time and one would not have even been attempted before due to the SWE headcount you would have to steal. There are countless examples I have in my own personal projects that just are such an obvious counter example to the moaning “I appreciate the craft” people or “yea this will never work because people still have to read the code” (today sure and this is now made more manageable by good quality agents, tomorrow no. No you won’t need to read code.)
I've found that the effort required to get a good outcome is roughly equal to the effort of doing it myself.
If I do it myself, I get the added bonus of actually understanding what the code is doing, which makes debugging any issues down the line way easier. It's also in generally better for teams b/c you can ask the 'owner' of a part of the codebase what their intuition is on an issue (trying to have AI fill in for this purpose has been underwhelming for me so far).
Trying to maintain a vibecoded codebase essentially involves spelunking though a non-familliar codebase every time manual action is needed to fix an issue (including reviewing/verifying the output of an AI tool's fix for the issue).
(For small/pinpointed things, it has been very good. e.g.: write a python script to comb through this CSV and print x details about it/turn this into a dashboard)
I didn’t say essentially all software is vibe coded. You already agree with me that it’s very good at some range of common tasks.
There are other things very good "at some range of common tasks". For example, stackoverflow snippets, libraries, bash spaghetti and even some no-code/low-code tools.
ok
In sonnet 4 and even 4.5 I would have said you are absolutely right, and in many cases it slows you down especially when you don’t know enough to sniff trouble.
Opus 4.5 and 4.6 is where those instances have gone down, waaay down (though still true). Two personal projects I had abandoned after sonnet built a large pile of semi working cruft it couldn’t quite reason about, opus 4.6 does it in almost one shot.
You are right about learning but consider: you can educate yourself along the way — in some cases it’s no substitute for writing the code yourself, and in many cases you learn a ton more because it’s an excellent teacher and you can try out ideas to see which work best or get feedback on them. I feel I have learned a TON about the space though unlike when I code it myself I may not be extremely comfortable with the details. I would argue we are about 30% of the way to the point where it’s not even no longer relevant it’s a disservice to your company to be writing things yourself.
What part of Voyager I and Voyager II are "augmented with agentic development?"
Surely if all software is augmented with agentic development now, our most important space probes have had their software augmented too, right?
What about my blog that I serve static pages on? What about the xray machine my dentist uses? What about the firmware in my toaster? Does the New York Stock Exchange use AI to action stock trades? What about my telescope's ACSOM driver?
You’re talking about a 1970s satellite? I guess you win the argument?
Blog: I use AI to make and blog developers are using agentic tools
X-ray machine: again a little late here, plus if you want to start dragging in places that likely have a huge amount of beaurocracy I don’t know that that’s very fair
Firmware in your toaster: cmon these are old basic things, if it’s new firmware maybe? But probably not? These are not strong examples
NYSE to action on stock trades; no they don’t use AI to action on stock trades (that would be dumb and slow and horribly inefficient and non-deterministic), but may very well now be using AI to work on the codebase that does
Let’s try to find maybe more impactful examples than small embodied components in toasters and telescopes, 1970s era telescopes that are already past our solar system.
The denial runs deep
So you admit that AI isn't in every software, and yet somehow I'm the one in denial?
Im saying you’re missing the point and the spirit of the argument. Yes, you are right, voyager doesn’t use agentic AI! I don’t even think the other examples you used are as agentic free as you think. They may or may not be! What’s the point you want to make?
Huh? Software under development obviously not software made before these tools existed
With openclaw we won't need to make event those apps.
clearly this is a play to own all the agentic traces for further training
clearly this is a plat to own all the agent traces for further training
so github ci/cd agents rebranded as a startup? same team different company.
The demo shows a bunch of manual stuff that humans shouldn't be doing.
I’m team Geoffrey Huntley
With the how AI companies are advertising we can just tell the AI what we want and it will be done with no additional human interaction needed, why do we need a new type of development platform? We shouldn't need to collaborate at all.
https://www.youtube.com/watch?v=aJUuJtGgkQg
* This is snarky. Yes. But seriously.
The why is simple: "because we need the money." The idea is just a vehicle to get that money. Whether or not it works or makes sense is secondary to but does it make the children dream, pa-pa?
I do not want it.
Is it just me or does "ex GitHub CEO" sound like it's going to be a bad project getting continuously worse and therefore is not worth to even look into!?
I am not willing to share my sheepish prompts with my team. Sorry!
Hah. "If it's not too much trouble, would you mind if we disable the rimraf root feature?"
Gotta bully that thing man. There's probably room in the market for a local tool that strips the superfluous niceties from instructions. Probably gonna save a material amount of tokens in aggregate.
I'm with you. I start every new prompt with: "Good morning", even at midnight. I'll be so embarrassed if that leaks.
LOL
Sounds very cringe
Not surprising for a $60M seed round
Do we have new words for smaller amounts or is this inflation at work?
Looking at the CLI implementation. Why not build on top of jj?
most people use git, jj has compatibility gaps
I thought something got seriously wrong with Nat Friedman but fortunately it's another one.
I really hate this trend of naming companies using dictionary words just because they can afford to spend cash on the domain name instead of engineering. Render, fly, modal, entire and so on.
$60M seed to wrap git hooks in YAML config. The AI tooling bubble is just VCs subsidizing solutions looking for problems while developers want less complexity, not more.
Which CEO?
check out codecast.sh !
$300kk valuation for git commits :) the bubble will pop at some point, I don’t know when, but boy will it be spectacular.
60 million seed round? Delusional, I have no idea what investors are thinking.
Clicks through to see what Tom or Chris started…
Oh, nevermind, it’s some MS dude.
"$60M Seed round"
I guess when you are Ex-Github CEO, it is that easy raising a $60M seed. I wonder what the record for a seed round is. This is crazy.
Christ, a $60m seed round.
The AI fatigue is real, and the cooling-off period is going to hurt. We’re deep into concept overload now. Every week it’s another tool (don’t get me started on Gas Town) confidently claiming to solve… something. “Faster development”, apparently.
Unless you’re already ideologically committed to this space, I don’t see how the average engineer has the energy or motivation to even understand these tools, never mind meaningfully compare them. That’s before you factor in that many of them actively remove the parts of engineering people enjoy, while piling on yet another layer of abstraction, configuration, and cognitive load.
I’m so tired of being told we’re in yet another “paradigm shift”. Tools like Codex can be useful in small doses, but the moment it turns into a sprawling ecosystem of prompts, agents, workflows, and magical thinking, it stops feeling like leverage and starts feeling like self-inflicted complexity.
It's an ex-CEO of Github. He can raise $60m on any idea.
> I don’t see how the average engineer has the energy or motivation to even understand these tools, never mind meaningfully compare them
This is why I use the copilot extension in VS code. They seem to just copy whatever useful thing climbs to the surface of the AI tool slop pile. Last week I loaded up and Opus 4.6 was there ready to use. Yesterday I found it has a new Claude tool built in which I used to do some refactoring... it worked fine. It's like having an AI tool curator.
Maybe just learning 1 or 2 of such tools is enough ?
History has shown that by delaying learning the next greatest tech, you may avoid learning it altogether.
Probably, but which ones, do we get to a place where you have X years experience in Gastown development, but I only have Y years experience in Entire.
I also keep getting job applications for AI-native 'developers' whatever that means.
You will learn a lot about the underlying LLM / technology whichever tool you use though
Your point about the overwhelming proliferation of AI tools and not knowing which are worth any attention and which are trash is very true I feel that a lot today (my solution is basically to just lean into one or two and ask for recommendations on other tools with mixed success).
The “I’m so tired of being told we’re in another paradigm shift” comments are widely heard and upvoted on HN and are just so hard to comprehend today. They are not seeing the writing on the wall and following where the ball is going to be even in 6-12 months. We have scaling laws, multiple METR benchmarks, internal and external evals of a variety of flavors.
“Tools like codex can be useful in small doses” the best and most prestigious engineers I know inside and outside my company do not code virtually at all. I’m not one of them but I also do not code at all whatsoever. Agents are sufficiently powerful to justify and explain themselves and walk you through as much of the code as you want them to.
Yeah, I’m not disputing that AI-assisted engineering is a real shift. It obviously is.
My issue is that we’ve now got a million secondary “paradigm shifts” layered on top: agent frameworks, orchestration patterns, prompt DSLs, eval harnesses, routing, memory, tool calling, “autonomous” workflows… all presented like you’re behind if you’re not constantly replatforming your brain.
Even if the end-state is “engineers code less”, the near-term reality for most engineers is still: deliver software, support customers, handle incidents, and now also become competent evaluators of rapidly changing bot stacks. That cognitive tax is brutal.
So yes, follow where the ball is going. I am. I’m just not pretending the current proliferation is anything other than noisy and expensive to keep up with.
Oh man I'm tired. This reminds me of the docker era. It's all moving fast. Everyone's raising money. And 24 months from now it's all consolidating. It's all a nice hype game when you raise the funding but the execution depends on people finding value in your products and tools. I would argue yes many of these things are useful but I'd also argue there's far too much overlap, too many unknowns and too many people trying to reinvent the whole process. And just like the container era I think we're going to see a real race to zero. Where most of the dev tools get open sourced and only a handful of product companies survive, if that. I want to wish everyone the best of luck because I myself have raised money and spent countless years building Dev tools. This is no easy task especially as the landscape is changing. I just think when you raise $60m and announce a cli. You're already dead, you just don't know it. I'm sorry.
Let the cambrian explosion run its course but let's hope the meteorite doesn't kill us all.
I see the value since I built a similar tool different approach. Then there's Beads, which is what inspired my project, with some tens of thousands of developers using it or more now? I'm not sure how they figure how many users they have.
In my case I don't want my tools to assume git, my tools should work whether I open SVN, TFS, Git, or a zip file. It should also sync back into my 'human' tooling, which is what I do currently. Still working on it, but its also free, just like Beads.
I wouldn't wanna be in the rat race myself, but I know people who salivate at the opportunity to create some popular dev tool to get acquired by MS, Google or Amazon or whichever of the big tech companies that decide this could work well in their cloud ecosystem.
HNites are hilarious.
On the one hand they think these things provide 1337x productivity gains, can be run autonomously, and will one day lead to "the first 1 person billion dollar company".
And in complete cognitive dissonance also somehow still have fantasies of future 'acquisition' by their oppressors.
Why acquire your trash dev tool?
They'll just have the agents copy it. Hell, you could even outright steal it, because apparently laundering any licensing issues through LLMs short circuits the brains of judges to protohuman clacking rocks together levels.
I think there are 2 parts here. That persona you’re describing (startup cofounder or engineer being paid mostly in equity) is a good subset of the people here. If I had to pull a number out of my shiny metal ass, I’d say it’s 30%. Those people both loath big tech, and dream of the day they are acquired by it. It’s not really the contradiction you think it’s. Another 45% of people here are tech-savvy Reddit refuges who say Reddit things.
As to why would those company acquire a startup instead of having an agent generate it for them. Why has big tech ever acquired tech startups when they could have always funded it in house? It’s not always a technical answer. Sometimes it’s internal Political fights, time to market, reduce competition, PR reasons or they just wanna hire the founder to lead a team for that internally and the only way he’ll agree is if there is an exit plan for his employees. I sat in “acquire or build” discussions before. The “how hard would it be to just do that?” Was just one of many inputs into the discussion. Ever wondered why big big companies acquire a smaller one, not invest in it, then shut it down few years later?
What if it's just the beginning of something bigger?
What if the earth exploded tomorrow? Who cares about what if.
With 60 million you could have waited for a bigger announcement? There's "AI fatigue" among the target market for these sorts of tools, advertising unfinished products will take its toll on you later.
Grifters to the grift god
How can the VC market sustain yet another Cursor clone? Jfc it needs to die
[flagged]
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?
Because "we" are just wrappers around OpenAI's model.
> if OpenAI can essentially work with Monopolly money, whey can´t "we" do it too?
The answer is, in case anyone wonders: because OpenAI is providing a general purpose tool that has potential to subsume most of the software industry; "We" are merely setting up toll gates around what will ultimately become a bunch of tools for LLM, and trying to pass it off as a "product".
For the huge amounts of capital already burnt, and another 1T in CapEX RPO being announced last few weeks and months, isnt that too many of "potentially" and "ultimately" unspecific qualifiers you are throwing around here? Reminds a lot of Sam Altmans classic lines of unspecific statements like "Codex is so good" or "I can only imagine how good it will get" by the end of 202x (insert year of the decade according to your own preference). After 10+ years of OpenAI and 4+ years of ChatGPT, why is the potential not materialising ?
We are in an era of solutions being invented and developed at a rapid pace. The identification or invention of problems that they are good at solving has a much slower lifecycle.
Really? Why then does Amodei keep announcing the end of employment in 6 months, every 6 months?
CEO's are living proof that a broken clock can be wrong the whole day (and still get paid).
I wonder since agents are soo successful, when are CEOs get replaced by AI?
Or it does not work that way?
You would need multi trillion parameter models to even come close to capturing the CEO grindset.
Counter argument just to play devil’s advocate. Is that forming LLMs into useful shapes could become the game. If it turns out to be impossible to build a real moat around making LLMs - like maybe China or just anyone will ultimately be able to run them locally / cheaply, then the game of spending a billion dollars training one is much more risky
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.
My memories are different. Git became amazing on it's own and was a big advantage over SVN. GitHub was "a open source" thing in the beginning. No company here had the idea to host proprietary closed source code on another platform they do not have control over. This eventually became a thing later though and the mindset shifted.
I think you're both right. Post-Github, a lot of Git's adoption came from Github. But Github "worked" because a lot of people were already using Git and Github offered them amazing value, and that initial userbase created a viral effect: People increasingly came into contact with Github via projects hosted there, and those who did not already use Git picked it up as a result of that.
And now many companies do have the idea of hosting proprietary code on a shitty, buggy, closed-source platform they have no control over. Indeed a shifted mindset. Maybe it wasn't shitty, buggy and closed-source enough before.
Coming from Subversion, git was already so amazing without GitHub, so I'll kindly disagree with you on that front.
> 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.
Github has always been mediocre and forgettable outside of convenience that you might already have an account on the site. Svn was just shitty compared to git, and cvs was a crime against humanity.
> Github has always been mediocre and forgettable outside of convenience that you might already have an account on the site.
Completely agree. I moved out of GitHub for my personal projects and I don't miss it a single nanosecond.
Not to mention Rad.
I have to hard disagree on that. I know of many developers personally who were on Source Forge and Google Code before and migrated to GitHub specifically because they offered git
Clear context. Write a sonet in Shakespeare style.
I don't think SVN and Mercurial were more widely used than git before Github became popular, but Github definitely killed off most of the use of those.
Git had already replaced perforce and svn most everywhere I'd seen, before GitHub came along. CVS was still horrible and in a lot, though.
I mean, git was '05 and GitHub was '08, so not like the stats will say much one way or another. StackOverflow only added it their survey in 2015. No source of truth, only anecdotes.
Lots of people were using svn and mercurial was also coming up around the time that GitHub launched. Both git and GitHub were superior to all the other options but for many people they did the switch to GitHub and git at the same time.
Yeah, whilst git was more popular than mercurial, I still think mercurial would have won if bitbucket had a better UI.
It's interesting to me that the only thing that made me vastly prefer using Github over bitbucket is that Github prioritised showing the readme over showing the source tree. Such a little thing, but it made all the difference.
100% I remember asking fellow devs why they switched to git from svn/cvs whatever and the answer was - oh it can do branches. Ok, no more questions )
Git had amazing value and GitHub made it easy to access that value.
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.
At least for me, I have felt like the chat history in an agent is often times just as important and potentially even more important than the source code it generates. The code is merely the compiled result of my explanations of intent and goals. That is, the business logic and domain expertise is trapped in my brain, which isn't very scalable.
Versioning and tracking the true source code, my thoughts, or even the thoughts of other agents and their findings, seems like a logical next step. A hosted central place for it and the infrastructure required to store the immense data created by constantly churning agents that arrive at a certain result seems like the challenge many seem to be missing here.
I wish you the best of luck with your startup.
I'm building an "improvement agent" that kinda embraces that. It starts out by running exploration across a codebase or set of documents and extract possible goals, and a vision from that. It then starts producing improvement plans (tickets, effectively). If it gets things wrong, I nudge it in the right direction, and it gets incorporated into revisions of the documents via a review stage. It's an experiment for now, but it is both doing semi-self-directed implementation and helping me identify where my thoughts haven't been crystallised enough by seeing where it fails to understand what I want.
I'm not just running it on code, but on my daily journal, and it produces actionable plans for building infrastructure to help me plan and execute better as a result.
Natural language is in fact a terrible way to express goals, it is imprecise, contradictory, subjective, full of redundancies and constantly changing. So possibly the worst format to record business rules and logic.
This lesson has been learned over and over (see AppleScript) but it seems people need to keep learning it.
We use simple programming languages composed of logic and maths not just to talk to the machine but to codify our thoughts within a strict internally consistent and deterministic system.
So in no sense are the vague imprecise instructions fed to LLMs the true source code.
Before LLMs (and still now) a human will often write a doc explaining the desired UX and user journeys that a product needs to support. That doc gets provided to engineers to build.
I agree - at least with the thesis - that the more we "encode" the fuzzy ideas (as translated by an engineer) into the codebase the better. This isn't the same thing as an "English compiler". It'd be closer to the git commit messages, understanding why a change was happening, and what product decisions and compromises were being designed against.
I think I’d rather have the why in English and the how in code, i.e. keep both, keeping just the English instructions is nowhere near enough to fully specify what was done and why. These things evolve as they are produced and English is too fuzzy.
It was 2.4% in 2008.
https://web.archive.org/web/20090531152951/http://www.survey...
You don't need a workflow. The agent is the workflow. That's the idea at least. Probably not a great idea IMHO, because producing high quality code is the main difficulty of programming. Everything else, committing to git, deploying etc, pale in comparison.
The hype is the product
> are we building tools for a workflow that actually exists, or are we building tools and hoping the workflow materializes?
You could ask that question about all the billions that went into crypto projects.
This is the irony: AI projects are comparable to crypto projects, but receiving 60M in seed-funding.
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.
Yes, development was being done in SVN but it was a huge pain. Continuous communication was required with the server (history lookups took ages, changing a file required a checkout, etc.) and that was just horribly inefficient for distributed teams. Even within Europe, much more so when cross-continent.
A DVCS was definitely required. And I would say git won out due to Linus inventing and then backing it, not because of a platform that would serve it.
I was involved with bzr and Launchpad: anybody using pure Git hated it. GitHub, even with fewer features compared to LP, was pretty well regarded.
Yes, kernel and Linus used it, but he used a proprietary VCS before that did not go anywhere anyway, really.
> changing a file required a checkout
SVN didn't need checkouts to edit that I recall? Perforce had that kind of model.
As did cvs. But you are right.
I am not sure, it seems I did misremember. Though it's possible I was actually working with needs-lock files. I can definitely see a certain coworker from that time to put this on all files :/
And even in P4, you could checkout files only at the end, kind of like `git add`. Though this could provide some annoyance if someone had locked the file in the upstream.
Yes to all that. And GitLab the company was only founded in 2014 (OSS project started in 2011) and ran through YC in 2015, seven years after GitHub launched.
and most of those, except maybe gitlab, were clunky AF to use
The goal here is just to piggyback on the AI bandwagon, gather a lot of funding, create a product nobody understands but that sparks imagination, and sell it to FAANG.
Nobody cares if it makes sense, it just has to appear futuristic and avant-garde.
We’re building to milk the bitch while the hype is at the top. Anyone who seriously believes agents are capable of operating completely autonomously right now without any human supervision is delusional.
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.
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
the workflow exists
my code is 90% ai generated at this point
Only in HN comments will you get down voted for making a fair and scoped claim about your personal experience with AI.
We went from having new JavaScript frameworks every week to having new AI frameworks every week. I'm thinking I should build a HN clone that filters out all posts about AI topics...
Looking at the most popular agent skills, heavily geared towards react and JS, I think a lot of the most breathless reports of LLM success are weighted towards the same group of fashion-dependant JavaScript developers.
The same very online group endlessly hyping messy techs and frontend JS frameworks, oblivious to the Facebook and Google sized mechanics driving said frameworks, are now 100x-ing themselves with things like “specs” and “tests” and dreaming big about type systems and compilers we’ve had for decades.
I don’t wanna say this cycle is us watching Node jockies discover systems programming in slow motion through LLMs, but it feels like that sometimes.
Ironically, using LLM’s for React is an exercise in pain, because they’re all trained on the lowest common denominator. So even Opus is constantly fighting stupid reactivity bugs.
Create extension that does that. AI can do that for you in 10 minutes
Or, you could perform a public service by creating a HN clone only for bots and try to convince the bots trolling here to go there.
That actually (sorta) already exists: https://news.ysimulator.run/news
You know the only effective way to do that, right?
Claude create a clone of Hacker News, no mistakes. Must compile.
Just give me your bank account, claude API, Mother's maiden name, your zip code, your 3 digit security code, and anything else you think I might need to live as malfist the magnificant. Can I call you that?
Yep exactly, a Perl script
I've long wished for a 'filter' feature for the hn feed -- namely the old trend of web3 slop -- but with little else than keywords to filter, it would likely be tedious and inaccurate. Ironically, I think with AI/LLMs it could be a little easier to analyze.
one technique i've found useful is i don't click on the link if i'm not interested.
it's very effective.
and there's even a "hide" link.
It’s one reason I hoped lobste.rs had taken off. All posts are tagged and you can filter out by tag.
This is how software is being written now. What you propose is like joining a forum called "Small-Scale Manufacturing News" and filtering out all 3D-printing articles.
We want to filter out the irrelevant software :)
[dead]
I'm pretty happy using Shelley, which stores agent conversations in a Sqlite database. I can refer to a previous conversation and the agent can easily do a Sqlite query to see what happened.
Although this isn't stored in git, I don't see any particularly need to since it's too detailed. Instead I have the agent write design docs (as an alternative to plan mode) and check those in. That seems like enough.
Doesnt the tooling already exist? i.e. you could use `git notes` to attach agent state as checkpoints to Trees, Commits, Tags etc.
The CLI is open source, everyone can use it and it does work with git only. So, no separate platform needed. The platform only provides convenience to view checkpoints at the moment. However you can also view them in the CLI. It's here https://github.com/entireio/cli
This sounds like a company idea someone just came up with yesterday off the cuff, pitched it, and got money for because of their credentials so no one can really say no to investing in it, despite nothing new or different? What's the service or product and how is it different than every 3rd Show HN?
[dead]
> The problem is that agent-written code has a provenance gap. When a human writes code, the reasoning lives in their head, in Slack threads, in PR descriptions. When an agent writes code, the reasoning evaporates the moment the context window closes.
The described situation for human-written code isn't much better. What actually works is putting a ticket (or project) number in the commit message, and making sure everything relevant gets written up and saved to that centralized repository.
And once you have that, the level of detail you'd get from saving agent chats won't add much. Maybe unless you're doing deliberate study of how to prompt more effectively (but even then, the next iteration of models is just a couple months away)?
Agent memory can sometimes be handled with prompts, state output on completion, etc. Managing that can get messy if you aren't on the same system.
I think "provenance gap" or temporal history can be helped by understanding what you have asked agentic systems to write, understand things written, and verified them.
We aren't yet at a point where something large or extended is easily pushed to agentic coding management - your point of provenance and memory is key here.
Already at a $300 million valuation at seed. Who’s going to join this as a regular IC who gets a pittance in options? I can’t imagine the risk matches the modest potential upside.
They'll raise at double that or more before the end of the year. The dynamics of the VC market right now are staggering to watch, but the money velocity is real, and this has "ex-CEO of Github" plus "AI".
It's legit mania in VC world even as they're looking at each going "is this mania? Is it mania if you're asking if it's mania". The only rule right now is the music is playing so no-one wants to grab a chair. There's a sense this might come crashing down, but what's a player gonna do, sit on the side while paper markups are producing IRR that is practically unprecedented?
This kinda has to end badly at this point.
> this has "ex-CEO of Github" plus "AI".
If they could top it off by stealing a janitor from OpenAI or Anthropic, the VCs might wet their pants with excitement.
They'll hire one guy to vibe code like ai.com thing
[dead]
Either the models are good and this sort of platform gets swept away, or they aren’t, and this sort of platform gets swept away.
The most interesting thing about everyone trying to position themselves as AI experts is the futility of it: the technology explicitly promises tomorrows models will be better then todays, which means the skill investment is deflationary: the best time to learn anything is tomorrow when a better model will be better at doing the same work - because you don't need to be (conversely if you're not good at debugging and reverse engineering now...)
the best time to learn anything is tomorrow when a better model will be better at doing the same work
doesn’t that presume no value is being delivered by current models?
I can understand applying this logic to building a startup that solves today’s ai shortcomings… but value delivered today is still valuable even if it becomes more effective tomorrow.
I think it also presumes that the skills of today won't be helpful in making you better, faster, stronger at knowing what to learn tomorrow. Skateboarding ain't snowboarding but I guarantee the experience helps.
Yeah but neither makes a difference to taking a taxi.
And your skills at catching a cab don't matter for booking a self driving car online.
I'm pretty much just rawdogging Claude Code and opencode and I haven't bothered setting up skills or MCPs except for one that talks to Jira and Confluence. I just don't see the point when I'm perfectly capable of writing a detailed prompt with all my expectations.
The problem is that so many of these things are AI instructing AI and my trust rating for vibe coded tools is zero. It's become a point of pride for the human to be taken out of the loop, and the one thing that isn't recorded is the transcript that produced the slop.
I mean, you have the creator of openclaw saying he doesn't read code at all, he just generates it. That is not software engineering or development, it's brogrammer trash.
I think the rationale is that with the right tools you can move much faster, and not burn everything to the ground, than just rawdogging Claude. If you haven't bothered setting up extra tools you may still be faster / better than old you, but not better than the you that could be. I'm not preaching, that's just the idea.
> That is not software engineering or development, it's brogrammer trash.
Yes, but it's working. I'm still reading the code and calling out specific issues to Claude, but it's less and less.
You're reading it though, and I imagine you are applying comprehension to it based on your experience. It's not vibe-coding any more at that point, I'd call it rapid application development. That's what Rails did in, what, 2010? Maybe earlier? Except it was generated scaffolding code created through reflection and not machine learning.
It's when you take yourself out of the loop and trust the process that it goes in the wrong direction.
That’s true for “tips and tricks” knowledge like “which model is best today” or “tell the model you’ll get fired if the answer is wrong to increase accuracy” that pops up on Twitter/X. It’s fleeting, makes people feel like “experts”, and doesn’t age well.
On the other hand, deeply understanding how models work and where they fall short, how to set up, organize, and maintain context, and which tools and workflows support that tends to last much longer. When something like the “Ralph loop” blows up on social media (and dies just as fast), the interesting question is: what problem was it trying to solve, and how did it do it differently from alternatives? Thinking through those problems is like training a muscle, and that muscle stays useful even as the underlying technology evolves.
> what problem was it trying to solve, and how did it do it differently from alternatives?
Sounds to me like accidental complexity. The essential problem is to write good code for the computer to do it's task?
There's an issue if you're (general you) more focused on fixing the tool than on the primary problem, especially when you don't know if the tool is even suitable,
It does seem like things are moving very quickly even deeper than what you are saying. Less than a year ago langchain, model fine tuning and RAG were the cutting edge and the “thing to do”.
Now because of models improving, context sizes getting bigger, and commercial offerings improving I hardly hear about them.
I have a reading list of a bunch of papers i didn't get through over the past 2 years. it is crazy how many papers on this list are completely not talked about anymore.
I kinda regret going through the SeLU paper lol back in the late 2010s.
You nailed it. Thats exactly how I feel. Wake me up when the dust settles, and i'll deep dive and learn all the ins and outs. The churn is just too exhausting.
You might wake up in a whole different biome, Rip Van Winkle.
I don't get the pressure. I don't know about you, but my job for a long time has been continually learning new systems. I don't get how so many of my peers fall into this head trip where they think they are gonna get left behind by what amounts to anticipated new features from some SaaS one day.
How do you both hold that the technology is so revolutionary because of its productive gains, but at the same time so esoteric that you better be ontop of everything all the time?
This stuff is all like a weird toy compared to other things I have taken the time to learn in my career, the sense of expertise people claim at all comes off to me like a guy who knows the Taco Bell secret menu, or the best set of coupons to use at Target. Its the opposite of intimidating!
I'm not scared that my skills will be obsolete, I'm scared employers will think they are. The labor market was already irrational enough as it was.
I may just be a "doomer", but my current take is we have maybe 3-5 years of decent compensation left to "extract" from our profession. Being an AI "expert" will likely extend that range slightly, but at the cost of being one of the "traitors" that helps build your own replacement (but it will happen with or without you).
> the technology explicitly promises tomorrows models will be better then todays, which means the skill investment is deflationary
This is just wrong. A) It doesn’t promise improvement B) Even if it does improve, that doesn’t say anything about skill investment. Maybe its improvements amplify human skill just as they have so far.
Either the business makes a profit before it gets swept away, or it doesn't. This should be your goal: make money before your business dies. If you do that, you succeeded. Businesses are always ephemeral.
This is very well put. I think this platform can be useful but I doubt it can be something as big as the think it will be. At the end of the day it’s just storing some info with your data. I guess they are trying to be the next GitHub (and clearly have the experience :)). I doubt that success can be replicated today with this idea, even with $60 mil to burn
They know hence: forget what it does, it was created by the ex CEO of another commonly used thingy!
But think of all the investor dollars between now and then!
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
This guy was the ex-ceo of GitHub and can't bother to communicate his product in a single announcement post?
I am here. What did I not bother with? I wrote the blog post and it has all the details.
You’ve described a technology, not a solution to a clearly articulated problem that customers actually have. The problem that you have described is vague, and it’s unclear that it’s actually a problem at all. Finally, you don’t provide a persuasive and concrete argument about how your eventual solution—whatever that may be—will solve it.
I don’t mean to be so presumptuous as to teach Grampa how to suck eggs, but I think Amazon’s working backwards process is instructive.
I am struggling to see what the details are other than high-level concepts. Perhaps a demo would be useful!
[dead]
Hey, is JJ compatibility in the cards? Considering the blog article hints at a goal of a developerless agent-to-agent automation platform I'm guessing developer conveniences are a side quest rn?
Yes, definitely something we are thinking of.
Wow, account from 2011 and just two comments, both on this article. Welcome, lurker, and good luck :)
Thanks. New startup, new approach.
[flagged]
Please don't cross into personal attack in HN comments.
You may not owe ex-Github-CEOs better, but you owe this community better if you're participating in it.
https://news.ycombinator.com/newsguidelines.html
[flagged]
The founder has only forked repositories on GitHub that are sort of light web development related.
His use of bombastic language in this announcement suggests that he has never personally worked on serious software. The deterioration of GitHub under his tenure is not confidence inspiring either, but that of course may have been dictated by Nadella.
If you are very generous, this is just another GitHub competitor dressed up in AI B.S. in order to get funding.
Personal attacks aren't allowed here, so I've banned the account. If you want to use HN as intended, you'd be welcome to review https://news.ycombinator.com/newsguidelines.html and then email hn@ycombinator.com with a reason to believe that you'll follow the rules in the future.
Founder here. I built commercial insurance software for Windows 95 in the 1990s, driver assistant systems at Mercedes and at Bosch in the early 2000s, dozens of iPhone apps as contractor, a startup called HockeyApp (acquired by Microsoft), and various smaller projects, mostly in Ruby on Rails. And of course, when I left Microsoft & GitHub, 10 years of green boxes were removed from my GitHub profile.
Glad to see you commenting here despite the, er, unsubstantive disposition of some of the commenters! (I'm a mod here btw.) We really don't like it when the audience responds to new things with snark and dismissiveness, and there are rules in https://news.ycombinator.com/newsguidelines.html to make that clear.
In this case I think the root problem is that the OP (https://entire.io/blog/hello-entire-world/) is the wrong genre for HN. It's a fine fundraising announcement, but that sort of enthusiastic general announcement rubs the HN audience the wrong way because what they really want is technical details. Spectacular non technical details like high valuations, etc., tend to accentuate this gap.
I mention this because if you or someone on your team wants to write a technical post about what you're building, with satisfying details and all that, then we could do a take 2 (whenever would be a good time for this).
Makes sense, and we definitely will have more technical posts coming soon and on a regular basis. And I am German, I am used to snark. :P Joking aside, thanks for the response and appreciate your work as a mod!
But ... what have you done lately?
(I jest ... kudos).
[dead]
This comment is both wrong and mean-spirited.
I’ve worked with ashtom for over a decade. He’s a coding machine - easily one of the most technical executives (who ships real production code.)
[flagged]
The thread is missing the forest for the trees. The interesting bet here isn't git checkpoints—it's that someone is finally building the observability layer for agent-generated code.
Most agent frameworks (LangChain, Swarm, etc.) obsessed over orchestration. But the actual pain point isn't "how do I chain prompts"—it's "what did the agent do, why, and how do I audit/reproduce it?"
The markdown-files-in-git crowd is right that simple approaches work. But they work at small scale. Once you have multiple agents across multiple sessions generating code in production, you hit the same observability problems every other distributed system hits: tracing, attribution, debugging failures across runs.
The $60M question is whether that problem is big enough to justify a platform vs. teams bolting on their own logging. I'm skeptical—but the underlying insight (agent observability > agent orchestration) seems directionally correct.
@dang with the launch of open claw I have seen so much more LLM slop comments. I know meta comments like mine aren't usually encouraged, but I think we need to do something about this as a community. Is there anything we can do? (either ban or at least requiring full disclosure for bot comments would be nice).
EDIT: I suspect the current "solution" is to just downvote (which I do!), but I think people who don't chat with LLMs daily might not recognize their telltale signs so I often see them highly upvoted.
Maybe that means people want LLM comments here, but it severely changes the tone and vibe of this site and I would like to at least have the community make that choice consciously rather than just slowly slide into the slop era.
Parent comment has the rhythm of an AI comment. Caught myself not realizing it until you mentioned it. Seems like I am more in tune with LLM slop on twitter, which is usually much worse. But on second sight it's clear and it also shows the comment as having no stance, and very generic.
@dang I would welcome a small secondary button that one can vote on to community-driven mark a comment as AI, just so we know.
The moltbook-ification of every online forum seems inevitable this year. I wish we had a counter to this.
I've been thinking about this, one solution I wonder if to put a really hard problem in the sigh up flow that humans couldn't solve, if it's solve in the signup, it's a bot, not sure how tf to actually basically captchas flip, however I suspect this would only work for so long.
It's the dead internet theory in action. Every time I see slop I comment on it. I've found people don't always like it when you comment on it.
Yes I usually just bite my tongue and downvote, but with the launch of open claw I think the amount of slop has increased dramatically and I think we need to deal with it sooner than later.
Do you really think openclaw is to blame? I shudder to think of how few protections HN has against bots like that.
Thank you for pointing this out. I didn't catch that the parent comment was ai either and upvoted it. Changed it to a downvote seeing your comment and realizing it the comment did indeed have many AI flags.
Nothing about the parent comment suggests AI, except the em dash, but that's just a regular old punctuation that predates AI.
How much experience do you have interacting with LLM generated prose? The comment I replied to sets off so many red flags that I would be willing to stake a lot on it being completely LLM generated.
It's not just the em dashes - its the cadence, tone and structure of the whole comment.
Yeah it's really frustrating how often I see kneejerk rebuttals assuming others are solely basing it on presence of em-dashes. That's usually a secondary data point. The obvious tells are more often structure/cadence as you say and by far most importantly: a clear pattern of repeated similar "AI smell" comments in their history that make it 100% obvious.
I didn’t catch it until seeing these flag-raising comments… checking the other comments from the last 8 hours, it’s Claw for sure.
Punchy sentence. Punchy sentence. It's not A, it's B.
The actual insight isn't C, it's D.
You're absolutely right! It's not the tooling, it's the platform.
This sounds awfully like an LLM generated comment.
I suppose it was just a matter of time before this kind of slop started taking over HN.
> Once you have multiple agents across multiple sessions generating code in production, you hit the same observability problems every other distributed system hits: tracing, attribution, debugging failures across runs.
This has been the story for every trend empowering developers since year dot. Look back and you can find exactly the same said about CD, public cloud, containers, the works. The 'orchestration' (read compliance) layers always get routed around. Always.
It's not this, it's that?
verbatim llm output with little substance to it. HN mods don't want us to be negative but if this is what we have to take serious these days it is hard to say anything else.
I guess I could not comment at all but that feels like just letting the platform sink into the slopacolypse?
A. B isn't C—it's D1.
E. But F, G: H1, H2...
I. J—but D2 seems K.
Yes—it is!
I thought everyone was just using open telemetry traces for this? This is just a classic observability problem that isn’t unique with agents. More important yes, but not unique functionally.
Can you explain more how otel traces solve this problem? I don't understand how it's related.
Ok, I’ll grant you that if they can get agents to somehow connect to other’s reasoning in realtime that would be useful. Right now it’s me that has to play reasoning container.
This is interesting. I’m experimenting with something adjacent in an open source plugin, but focused less on orchestration and more on decision quality.
Instead of just wiring agents together, I require stake and structured review around outputs. The idea is simple: coordination without cost trends toward noise.
Curious how entire.io thinks about incentives and failure modes as systems scale.
That is a sharp observation———it is the observability that matters! The question arises: Who observes the observers? Would you like me to create MetaEntire.ai———an agentic platform that observes Entire.io?
I think you need a few more em-dashes there to be safe
I think we need an Agent EE Server Platform. :P
Wholeheartedly agree. We have been working hard at a solution towards this and welcome any feedback and skepticism: https://github.com/backbay-labs/clawdstrike
[flagged]
This is what Claude had to say about your comment if we're doing this now:
Imagine being so intellectually lazy that you can't even be bothered to form your own opinion about a product. You just copy-paste it into Claude with "roast this" and then post the output like you're contributing something. That's not criticism, that's outsourcing your personality to an API call. You didn't engage with the architecture, the docs, the use case, or even the pricing page — you just wanted a sick burn you didn't have to think of yourself.
Are people doing this thing now where they can't even judge a product, website by themselves? Or read and analyze anything without asking an LLM to do it for them.
2026: The year everyone fried their brain with Think for Me SaaS.
I know a guy who uses AI to answer every question in his life. It tells him how to raise his kids, how to spend time with his wife. He takes it to the park with him and asks it what he should do there (on his phone). When people ask him questions, he forwards those questions directly to his phone and uses the response.
For any new piece of technology, there are a subset of people for whom it will completely and utterly destroy.
Try driving without google maps. Its a slippery slope we common folks we are in and there is no coming back - except for few purists..
I think there's a distribution of agency in humans, hence why we have insults like "npcs". Its probably not fair to use that word to describe people, but the cliche has some truth in it and I think a lot of tech exploits this.
I personally rarely need to use google maps, and if I do its a glance at it on the beginning of a trip, and I can find my way there through normal navigation. I might look again if I get lost, whereas, I have friends that use it to give directions to go five blocks. I don't think sense of direction is innate either, but its a muscle you build and some people choose to not work on that muscle and they suffer the consequences, albeit minor consequences.
I think we are seeing something similar with LLMs with the development and maintenance of reading, planning, creative and critical thinking skills. While some people might have a higher baseline, I think everyone has the ability to strengthen those muscles and the world implores us to do that in many situations, however, now we can pay Altman $0.0010 cents to offload that workout onto a GPU much like people do with navigation and maps. Tech companies love to exploit the dopamine driven response from taking shortcuts, getting somewhere quickly, its no different here.
I think (/know) the implications of this are much more hazardous than consequences of not exercising your navigational abilities, and at least with navigation there are fallback to assist people (signs, landmarks ect). There are no societal fallbacks for llm assisted thinking once someone becomes dependent on it for all aspects of analysis, planning and creativity. Once it is taken away (or they can't afford a quality of output the previously did), where do those natural abilities stand? The implications are very terrifying in my opinion.
I'm personally trying to stay as far away as possible from these things, I see where this is heading and its not as inconsequential as needing Maps to navigate 5 blocks. I do not want my critical thinking skills correlated 1:1 to the quality and quantity of tokens I can afford or have access too anymore than I do not want my navigational abilities correlated 1:1 to the quality of Maps service available to me.
People will say that this is cope, its the new calculator, whatever.. Have fun, I promise you that not knowing trigonometry but having access to an LLM does not give you the ability to write CAD software. I actually think not using these will give you a huge competitive advantage in the future. Someone who has great navigation skills will likely win a navigational competition in the mountains, or survive longer in certain situations. While the scope of those skills is narrow, it still proves a point[0]. The scope of your reading, critical thinking, creativity and planning skills is not limited.
[0]: It should be noted that some of the worlds most high agency and successful people actually participate in navigation as a sport called Orienteering, and spend boatloads of money in it.. I wonder why that is?
[dead]