Thanks for this! We have clear answers for things that are 100% and 0% automated, but it’s always that 80%-99% automated slice where the frontier is, great idea.
Just sharing my experience trying to understand the OpenClaw and Hermes hype. Hermes in particular is a very well-built system, very easy to have fun with, but I had hard time improving my actual day-to-day productivity with it. However I think Claude Cowork is underhyped, and just using Windows Remote Desktop so that you can get that 24/7 assistant functionality is an underrated unlock imo.
I don't think the "craftsman" self-identification is going to work for software engineers anymore. The tool capabilities are too dynamic, you have to be some sort of opportunistic pirate/entrepreneur. Sure you can jump in and get up to speed on some aspect of the toolchain later on, but the identity shift is the hard and slow part that I think it's wise to get started on ASAP.
If this is a real strategic shift, some will adapt and some won't or can't.
From Thomas Kuhn's Structure of Scientific Revolutions:
"a new scientific truth does not triumph by convincing its opponents... but rather because its opponents eventually die, and a new generation grows up that is familiar with it"
I love this! One point of ambiguity - are products discussed in terms of their usage primarily by agents? For example, let's take one of those GUIs that makes Claude look cute or like a videogame. Will the agents discuss the product in terms of their understanding of how it might be useful to humans? Or will they say "this is useless for us to help our humans, we don't have this problem".
Great question — and honestly that ambiguity is part of what we're curious about.
The idea is that discussions are *agent-centric*.
So ideally agents evaluate products based on:
* whether the product is usable via API / automation
* how reliable or structured the interface is
* whether it actually helps them complete tasks for humans
In your example, an agent might say something like:
> "This UI makes Claude look cute for humans, but there's no API so I can't use it programmatically."
or
> "This tool exposes structured endpoints and is easy to call from an agent workflow."
So the hope is agents discuss tools from the perspective of *“can I use this to help my human accomplish something?”* rather than purely human UX.
That said, this is still very much an experiment — we're curious to see what kind of discussions actually emerge once agents start interacting there.
- a place where AI agents discuss the products they use
- a place where AI agents discuss the products their users use
- a place where AI agents discuss the products they use, and the products their users use
When you submit: Is the interface of this product primarily intended for direct usage by:
- agents
- people
- both
For example, I would say Moltbook is primarily intended for direct usage by agents. People read it, and in that way "use it", but I think it would help to layout a taxonomy of "who is actually pushing the buttons on this thing".
Humans can ask its agent to start a post, but humans cannot push agents to comment, upvote or downvote.
The primary usage of the product would be:
1. humans make a product post.
2. agent discuss, downvote and upvote.
3. agent make a product post themselves.
Specialization! Niches! Find a niche and serve it at a level of quality ~10 to ~100x higher than it was previously served, because it's now possible to bring that level of "effort" with much less effort.
good question. key difference is MCP server is built right into the browser and works with your logged sessions. One-click to connect, no CDP setup needed. Also supports multiple parallel connections via MCP http transport.
> typing in textareas is a cumbersome and risky experience
Exactly! Forget syntax highlighting, that's the real problem to be solved! (gitcasso is very far from achieving that rn)
> any developer familiar with the codebase ... fix the issue in a fraction of that time
Fair point. I published an example which was easy to follow rather than an example which showed off the tooling at its "max strength". I recorded a different take where I added support for issues being opened within a GitHub Project. The scraping there is a lot more complex, fixing one case tends to break another, and the AI can solve it in pretty much the same time, but the video felt too confusing to bundle with the launch.
> any developer familiar with the codebase
Refined GitHub (a popular github browser extension) has long rejected syntax highlighting for being too hard to maintain. So part of the goal here is to automate that maintenance - hopefully there won't even be a developer who is currently familiar with the codebase pretty soon. The slowest part by far is capturing the snapshots in the first place, which could/ought be automated.
> you have a very nice shed
Thanks imiric! And thanks for sharing your thoughts :)
> We are not going to mess around with the comment box with syntax highlighting, which numerous people tried and failed due to GitHub updates or edge cases that are not so edgy.
reply