It's fascinating to see new UI primitives and concepts get invented in the LLM era. The sea of creativity makes it hard to even understand most of what each new app does, and nobody describes them well. When I went to the Hermes agent web page, I was left with zero clue about what it did or what it could do. It took a bit of digging to find the right part of the qm page that helped me grok what was going on.
I've become attached to Orca (yc-backed) for managing coding sessions in the past week, but some sort of postgres session db is what's really lacking. So, maybe it's time to try qm.
I think we need a new area of study around UI/Agent connection. It can kinda be done with tools, but I'd we need much deeper primitives to allow the UI to inform the Agent and vice-versa. Right now we've just given up, replacing the UI with an Agent message view, but I think that's just because nobody is thinking about how the two can compliment each other
I've been playing around with using a hidden markov model informed by a UI state event stream, with the end state fed into the Agent as a hint on each message turn. Then the Agent can make a tool call to add events to the HMM. This has been really interesting, but I haven't struck the right balance to make it actually feel good for the user yet
i find something a bit funny in an ai project, written by ai, requiring human-written text with specific guidance to not use ai.
"Given that coding agents write most underlying code now, we'd prefer PRs in the form of human-written text. [...] Please do not have AI artificially expand what you'd like to do into a formal proposal."
That's not surprising. I have much the same thing in my latest open-source work[0]. I have a workflow that's working nicely with agents, it's more of a pain to review someone else's code than it is to get a well-written description of their problem.
Coding agents are extremely useful but often extremely dumb with design. If you do not design the software yourself, you will probably get slop. This was always the core issue with vibe coding.
AI Averages, and is inclined to do average designs and implementations, which in some cases might be an improvement, but long term it creates more to deal with.
Because competent people are evaluating it. In places where the standards are rock-bottom, the AI is leagues ahead of anything they'd produce normally.
Well, if they're consistent, the ADR directory contains only human written text that drives the underlying development... Aaand it's empty. Well.
I personally would probably have the readme generated based on that directory as the primary document, probably with another `readme_generation_rules.md` in the ADRs directory, and I would be pretty ruthless about disallowing all the slop-adjacent wording.
i read the emphasized "human-written" part, in combination with that last line, as a blanket restriction (for contributing). but perhaps i read it wrong.
The hardest problem in multiplayer agents, at least for us, has not been the agent loop. It is scoping and QM's per-person scopes plus shared rooms is a sane answer for a company-wide assistant.
I build in the adjacent lane, AQ (aq.dev), a multiplayer coding harness where teams run Claude Code and Codex together), so seeing YC ship "a multiplayer agent harness for work" is validating and a little surreal.
Still figuring it out, but it's been really convenient to have an always-on agent that has access to internal systems and can be triggered by webhooks. Some examples of what we use it for:
- automatically fixing simple CI failures
- getting production alerts and automatically creating RCAs and a fix PR
- periodically checking slow DB queries and finding ways to speed them up.
- creating charts to answer one-off questions about our data
I've tried using it as an on-the-go coding agent as well, but found I prefer more interactive agents, so I can see what the code looks like.
I think the interesting challenge isn’t running agents, it’s reviewing their work. The more code agents produce, the more important provenance, review ergonomics, and trust become. I also suspect repository platforms will need to evolve there over the next few years.
Hermes is huge and packed with features you probably don't need. I prefer smaller one I can extend as necessary, there are so many on github now and it is fun to test them but have been impressed with dirge (https://github.com/dirge-code/dirge) not affiliated.
I have one reading my second tier RSS feeds and newsletters and giving me news/market updates filtered for things important to me
I'm not contradicting this but offering a contrast, I like Hermes because it simultaneously lowers barrier of entry and shows you what possibilities are unlocked by agents. I don't think I would have the time, interest or creativity to jump into the deep end by either extending an existing harness or rolling my own from the start. This also isn't an argument for doing just that, I might do so in the future, but critically only after Hermes has shown me what's possible and my preferences are developed.
I had the same line of thought and spent a while with nanoclaw before realizing that adding the features I want back in would have made future updates too painful. I ended up switching to Hermes and aggressively disabling tools/skills and it's been pretty fine so far. I got more use cases set up than I did in my time with nanoclaw.
I'm currently using it to help me with my oncall, first responder to our any production alerts. It's not as efficient as coding agent by default, but it's been tremendously helpful to me.
hermes is great to get started with, but it's packed to the gills with stuff you'll probably use one time just to test it. and this eats in to your context so if you're hoping to run it on a lighter-weight local model you'll run in to some trouble. if you go into it planning to customize/thin it out it's solid
At least for me, I often have a hard time believing people’s stated reasons for whatever they’re doing.
The substance <> narrative relationship is backwards a lot of the time. Someone does something for a nebulous multitude of reasons, and then post-hoc fits their decision-making into a logical explanation that sounds nice.
There is some psychology research supporting this as well.
I suppose if you see the narrative itself as part of the release, that might be interesting. But most of the time I’d rather just hear plainly and straightforwardly what the thing is.
Or at the very least, I am very accepting of releases which do not include rationalization / narrativization and don’t think it’s required to include.
Interesting to see they shipped an "anti-slop" taste skill:
> description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
> - *PREMIUM-CONSUMER PALETTE BAN (mandatory, second-most-recurring AI-tell):*
- For premium-consumer briefs (cookware, wellness, artisan, luxury, heritage craft, DTC home goods, etc.)...
- Backgrounds: `#f5f1ea`, `#f7f5f1`...
> Landing pages and portfolios are *visual products*. Text-only pages with fake-screenshot divs are slop.
Doesn’t this just lead to a new “basin of tastelessness” that, sure, looks different from current slop, but is itself just eventually slop all the same?
looks like an internal tool that yc rushed out the door to minimize any most lost ground to Buzz. That said, I'd be curious what folks think comparing these two tools.
it says
"Each deployment runs in the operator's own cloud account"
But feels like its written to run on one mac/vm and carries same drawbacks of other similar platforms. I'd rather use Hermes/Openclaw for oss or closed managed agents like Tasklet or Prajvis
> We take contributions as human-written text, not code — see CONTRIBUTING.md. Describe the change you'd like informally in a .txt or .md file in adrs/, and if we're aligned we'll handle the implementation.
Interesting approach to open source contributions. Closer to feature requests at that point?
>We take contributions as human-written text, not code — see CONTRIBUTING.md. Describe the change you'd like informally in a .txt or .md file in adrs/, and if we're aligned we'll handle the implementation. Report vulnerabilities privately — see SECURITY.md, not a public issue.
Starting to think people were right when they talked about our industry itself having an AI psychosis problem.
As someone who has maintained an open source project, I much prefer written bug reports and feature requests to drive-by PRs. (I almost don't even care if they are LLM-written.)
I appreciate open source maintainers and understand that it's a lot of thankless work, and I know what I'm about to say comes off as (and probably is) ignorant but the hoops projects make me jump through to report hugs or security issues is often like working for corporate in terms of bureaucracy and a lot of times I just don't bother. I've reported a few dozen bugs so I'm not prolific here but also not speaking without any experience at all. And then you often have automation (eg. Debian) closing bugs because nobody looked at it and saying to reopen it if it's still a problem in the current release.
Like I said, I do understand and appreciate how annoying it must be. But there are two ways to look at this, one is that it's free software a bug report is like a support request - and of course nobody should expect free support. The other way to look at it is that by reporting bugs I'm volunteering as QA for the project and the report is beneficial.
I sometimes add a PR with the fix for a bug report I make, but the last few have been ignored in favor of the maintainer's own code. So I think I'll stop doing PRs and just point to code lines instead.
In their case, it's motivated by a desire to keep copyrighted code out of the SQLite implementation, but I'm sure it has a nice benefit of making it so that an extremely widely used project doesn't get drive by, low effort code review requests while still allowing the community to engage.
Asking that "random people on the internet" don't sent code is not altogether a novel, post-AI idea.
I tend to think we have an industry AI mania problem, but I’m not sure I understand what you find psychotic about this. I find it better to get a text suggestion or description of the change, then work on the implementation myself, even without using an agent, instead of reviewing LLM diffs that I know I will want to tweak to my taste
Sounds to me they're asking people to basically at least put the starting stones to something that looks like a specification. Not a bad idea to gate the flurry of feature requests to people who actually can think 10-15 minutes about the feature they're suggesting/asking for.
It's fascinating to see new UI primitives and concepts get invented in the LLM era. The sea of creativity makes it hard to even understand most of what each new app does, and nobody describes them well. When I went to the Hermes agent web page, I was left with zero clue about what it did or what it could do. It took a bit of digging to find the right part of the qm page that helped me grok what was going on.
I've become attached to Orca (yc-backed) for managing coding sessions in the past week, but some sort of postgres session db is what's really lacking. So, maybe it's time to try qm.
AI needs entirely new primitives in many areas.
I think we need a new area of study around UI/Agent connection. It can kinda be done with tools, but I'd we need much deeper primitives to allow the UI to inform the Agent and vice-versa. Right now we've just given up, replacing the UI with an Agent message view, but I think that's just because nobody is thinking about how the two can compliment each other
I've been playing around with using a hidden markov model informed by a UI state event stream, with the end state fed into the Agent as a hint on each message turn. Then the Agent can make a tool call to add events to the HMM. This has been really interesting, but I haven't struck the right balance to make it actually feel good for the user yet
i find something a bit funny in an ai project, written by ai, requiring human-written text with specific guidance to not use ai.
"Given that coding agents write most underlying code now, we'd prefer PRs in the form of human-written text. [...] Please do not have AI artificially expand what you'd like to do into a formal proposal."
That's not surprising. I have much the same thing in my latest open-source work[0]. I have a workflow that's working nicely with agents, it's more of a pain to review someone else's code than it is to get a well-written description of their problem.
0: https://github.com/pjlsergeant/byre?tab=contributing-ov-file
XY problem, don't expand the design doc before you have the idea for the design. Don't compile down into lower abstraction levels until necessary
Coding agents are extremely useful but often extremely dumb with design. If you do not design the software yourself, you will probably get slop. This was always the core issue with vibe coding.
AI Averages, and is inclined to do average designs and implementations, which in some cases might be an improvement, but long term it creates more to deal with.
Hm. If "AI averages," then why doesn't it create an average amount to deal with, instead of more?
Because competent people are evaluating it. In places where the standards are rock-bottom, the AI is leagues ahead of anything they'd produce normally.
Because the “average” developer is incompetent.
Yet the README is generated ("Two skills maintain the boundary in both directions.") and the demo is .. a Mobius strip?
I'd prefer if you explain what it is you are building in the form of human-written text.
Well, if they're consistent, the ADR directory contains only human written text that drives the underlying development... Aaand it's empty. Well.
I personally would probably have the readme generated based on that directory as the primary document, probably with another `readme_generation_rules.md` in the ADRs directory, and I would be pretty ruthless about disallowing all the slop-adjacent wording.
They specifically ask not to create/submit a formal proposal. I do not see any restriction on the use of AI otherwise.
i read the emphasized "human-written" part, in combination with that last line, as a blanket restriction (for contributing). but perhaps i read it wrong.
List of commits already include at least two contributors who are openly working with Claude on their code: https://github.com/yc-software/qm/commits/main/
Love seeing this direction along with Buzz.
The hardest problem in multiplayer agents, at least for us, has not been the agent loop. It is scoping and QM's per-person scopes plus shared rooms is a sane answer for a company-wide assistant.
I build in the adjacent lane, AQ (aq.dev), a multiplayer coding harness where teams run Claude Code and Codex together), so seeing YC ship "a multiplayer agent harness for work" is validating and a little surreal.
Is Hermes the best openclaw like agent as they mention running it before?
Also, what are power uses really using openclaw like systems for?
Still figuring it out, but it's been really convenient to have an always-on agent that has access to internal systems and can be triggered by webhooks. Some examples of what we use it for:
- automatically fixing simple CI failures
- getting production alerts and automatically creating RCAs and a fix PR
- periodically checking slow DB queries and finding ways to speed them up.
- creating charts to answer one-off questions about our data
I've tried using it as an on-the-go coding agent as well, but found I prefer more interactive agents, so I can see what the code looks like.
I think the interesting challenge isn’t running agents, it’s reviewing their work. The more code agents produce, the more important provenance, review ergonomics, and trust become. I also suspect repository platforms will need to evolve there over the next few years.
Hermes is huge and packed with features you probably don't need. I prefer smaller one I can extend as necessary, there are so many on github now and it is fun to test them but have been impressed with dirge (https://github.com/dirge-code/dirge) not affiliated.
I have one reading my second tier RSS feeds and newsletters and giving me news/market updates filtered for things important to me
I'm not contradicting this but offering a contrast, I like Hermes because it simultaneously lowers barrier of entry and shows you what possibilities are unlocked by agents. I don't think I would have the time, interest or creativity to jump into the deep end by either extending an existing harness or rolling my own from the start. This also isn't an argument for doing just that, I might do so in the future, but critically only after Hermes has shown me what's possible and my preferences are developed.
I had the same line of thought and spent a while with nanoclaw before realizing that adding the features I want back in would have made future updates too painful. I ended up switching to Hermes and aggressively disabling tools/skills and it's been pretty fine so far. I got more use cases set up than I did in my time with nanoclaw.
I'm currently using it to help me with my oncall, first responder to our any production alerts. It's not as efficient as coding agent by default, but it's been tremendously helpful to me.
Honestly the limitations/security of it kind of made it a novelty for me. I use web hosted stuff like surfboard now for my llm-assistant work stuff.
I think most people use it to poll their email and instant messages and whateva with an LLM
hermes is great to get started with, but it's packed to the gills with stuff you'll probably use one time just to test it. and this eats in to your context so if you're hoping to run it on a lighter-weight local model you'll run in to some trouble. if you go into it planning to customize/thin it out it's solid
What is yc software?
I think it's the website you're on
Someone from Y Combinator made some software. Must there be narrativization of everything?
Yes, please!
I'd like to know more, for example why now?
At least for me, I often have a hard time believing people’s stated reasons for whatever they’re doing.
The substance <> narrative relationship is backwards a lot of the time. Someone does something for a nebulous multitude of reasons, and then post-hoc fits their decision-making into a logical explanation that sounds nice.
There is some psychology research supporting this as well.
I suppose if you see the narrative itself as part of the release, that might be interesting. But most of the time I’d rather just hear plainly and straightforwardly what the thing is.
Or at the very least, I am very accepting of releases which do not include rationalization / narrativization and don’t think it’s required to include.
Interesting to see they shipped an "anti-slop" taste skill:
> description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
> - *PREMIUM-CONSUMER PALETTE BAN (mandatory, second-most-recurring AI-tell):* - For premium-consumer briefs (cookware, wellness, artisan, luxury, heritage craft, DTC home goods, etc.)... - Backgrounds: `#f5f1ea`, `#f7f5f1`...
> Landing pages and portfolios are *visual products*. Text-only pages with fake-screenshot divs are slop.
https://github.com/yc-software/qm/blob/7f2c916360f1797a8ff2a...
Doesn’t this just lead to a new “basin of tastelessness” that, sure, looks different from current slop, but is itself just eventually slop all the same?
So just an accelerated version of the standard UI design trends cycle (which is bad).
looks like an internal tool that yc rushed out the door to minimize any most lost ground to Buzz. That said, I'd be curious what folks think comparing these two tools.
it says "Each deployment runs in the operator's own cloud account"
But feels like its written to run on one mac/vm and carries same drawbacks of other similar platforms. I'd rather use Hermes/Openclaw for oss or closed managed agents like Tasklet or Prajvis
> We take contributions as human-written text, not code — see CONTRIBUTING.md. Describe the change you'd like informally in a .txt or .md file in adrs/, and if we're aligned we'll handle the implementation.
Interesting approach to open source contributions. Closer to feature requests at that point?
>We take contributions as human-written text, not code — see CONTRIBUTING.md. Describe the change you'd like informally in a .txt or .md file in adrs/, and if we're aligned we'll handle the implementation. Report vulnerabilities privately — see SECURITY.md, not a public issue.
Starting to think people were right when they talked about our industry itself having an AI psychosis problem.
As someone who has maintained an open source project, I much prefer written bug reports and feature requests to drive-by PRs. (I almost don't even care if they are LLM-written.)
I appreciate open source maintainers and understand that it's a lot of thankless work, and I know what I'm about to say comes off as (and probably is) ignorant but the hoops projects make me jump through to report hugs or security issues is often like working for corporate in terms of bureaucracy and a lot of times I just don't bother. I've reported a few dozen bugs so I'm not prolific here but also not speaking without any experience at all. And then you often have automation (eg. Debian) closing bugs because nobody looked at it and saying to reopen it if it's still a problem in the current release.
Like I said, I do understand and appreciate how annoying it must be. But there are two ways to look at this, one is that it's free software a bug report is like a support request - and of course nobody should expect free support. The other way to look at it is that by reporting bugs I'm volunteering as QA for the project and the report is beneficial.
I sometimes add a PR with the fix for a bug report I make, but the last few have been ignored in favor of the maintainer's own code. So I think I'll stop doing PRs and just point to code lines instead.
SQLite has a conceptually similar contribution process:
> the project does not accept patches from random people on the internet
https://sqlite.org/copyright.html
In their case, it's motivated by a desire to keep copyrighted code out of the SQLite implementation, but I'm sure it has a nice benefit of making it so that an extremely widely used project doesn't get drive by, low effort code review requests while still allowing the community to engage.
Asking that "random people on the internet" don't sent code is not altogether a novel, post-AI idea.
I tend to think we have an industry AI mania problem, but I’m not sure I understand what you find psychotic about this. I find it better to get a text suggestion or description of the change, then work on the implementation myself, even without using an agent, instead of reviewing LLM diffs that I know I will want to tweak to my taste
Sounds to me they're asking people to basically at least put the starting stones to something that looks like a specification. Not a bad idea to gate the flurry of feature requests to people who actually can think 10-15 minutes about the feature they're suggesting/asking for.
as a maintainer, seems nicer than getting a slop pr with no context.
So, basically,
> Please write our prompts for us
the other option is to generate 5000+ open issues that no one cares are open.
Also, it's a AI project; what, exactly, do you think they're going to try and do?
Other than the hosting providers, who has made money directly from running OpenClaw in constant loops?
This software appears to be yet another solution in search of a problem designed to burn as many tokens as possible.
Sweet, now YC itself will be the startup :D.