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 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.
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.
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?
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?
> 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.
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...
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.
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.
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.
The context preservation problem is genuinely painful - I've been using task.md files and CLAUDE.md conventions to maintain agent state across sessions, and it's duct tape at best. First-class "checkpoints" that capture reasoning alongside diffs is an appealing idea.
But I'm skeptical of building this as a separate platform rather than as tooling on top of git. The most useful AI dev workflow improvements I've seen (cursor rules, aider conventions, claude hooks) all succeeded precisely because they stayed close to existing tools. The moment you ask developers to switch their entire SDLC stack, adoption becomes the real engineering challenge - not the tech.
Curious whether the open source commitment means the checkpoint format itself will be an open spec that other tools can build on.
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
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
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.
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
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.
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.
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.
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.
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'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.
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...
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.
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.
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?
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 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.
Let the cambrian explosion run its course but let's hope the meteorite doesn't kill us all.
What if it's just the beginning of something bigger?
What if the earth exploded tomorrow? Who cares about what if.
> 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.
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"
They'll learn soon enough that selling to developers necessitates speaking clearly.
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?
I couldn’t figure out what they were doing in the first few screens of scrolling. Moved on.
You need to use AI to summarize the point of articles about AI products
It is not the system that is on crack ...
Think of all of the habit tracker and to do list apps we'll be able to make now!
With openclaw we won't need to make event those apps.
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?
> 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.
https://github.com/Giancarlos/GuardRails
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...
Create extension that does that. AI can do that for you in 10 minutes
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.
It’s one reason I hoped lobste.rs had taken off. All posts are tagged and you can filter out by tag.
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.
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.
"$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.
The context preservation problem is genuinely painful - I've been using task.md files and CLAUDE.md conventions to maintain agent state across sessions, and it's duct tape at best. First-class "checkpoints" that capture reasoning alongside diffs is an appealing idea.
But I'm skeptical of building this as a separate platform rather than as tooling on top of git. The most useful AI dev workflow improvements I've seen (cursor rules, aider conventions, claude hooks) all succeeded precisely because they stayed close to existing tools. The moment you ask developers to switch their entire SDLC stack, adoption becomes the real engineering challenge - not the tech.
Curious whether the open source commitment means the checkpoint format itself will be an open spec that other tools can build on.
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
Looking at the CLI implementation. Why not build on top of jj?
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
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.
This guy was the ex-ceo of GitHub and can't bother to communicate his product in a single announcement post?
I saw him speak at a conference a couple of years ago. He couldn't communicate back then either, so at least he's consistent.
I am here. What did I not bother with? I wrote the blog post and it has all the details.
I am struggling to see what the details are other than high-level concepts. Perhaps a demo would be useful!
Wow, account from 2011 and just two comments, both on this article. Welcome, lurker, and good luck :)
Thanks. New startup, new approach.
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.
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.
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.
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
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.
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'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.
My first thought that it was made for companies which tie "AI usage" to performance evaluation.
Wait, since when is Dohmke out? I thought this was gonna be Nat.
> Cursor's Composer 2.0
There is no Composer 2.0. There is Cursor 2.0 and Composer 1.5.
Its a shame Pierre shut down. Wish they could have made it work. Github but made by Linear would be a dream.
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
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...
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.
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
> ... 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 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.
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
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?