Such a great read! I kept on nodding and chuckling the whole time reading it. I can see myself as the founder, especially 'spending time in the oven forums' lol.
I went to the /blog route to see other posts by the author, but alas, there is only this one! And that's a gem.
Thanks for the note.
While building the context bundle, there is a tool that detect gaps in the timeline. So when you ask 'kitchen renovation', and there are emails from 2019 and 2023, the tool flags these gaps and the LLM is made aware of it. So Memento asks which of these clusters you want to track as a project.
Later while generating the wiki, LLM handles conflicts and facts that evolved over time because it has the timestamp of the messages. So it shows that in the narrative.
Wwat we haven't implemented yet is to update the wiki when new emails arrive. That is the next one in our backlog.
We built Memento for two reasons - we were frustrated by the search in Gmail, and we wanted to organize email locally in a privacy-friendly way. But the outcome was much more than that - we learned how to build agents from scratch, optimize agentic search, and discovered many beautiful memories we didn’t know were hidden in our email.
We would love to know what you think of this project. All feedback is welcome.
Obviously the person who built and deployed the agent (the claw in this case).
If we treat this as a hard question, we risk treating AI systems as people rather than tools. This is exactly what Armin warned about in his "clanker" post last week.
As I understand, this skill is intended to understand AI-generated code and potentially reduce skill atrophy. So it asks the agent to pause after important milestones (eg: created a file, changed db schema etc ) and ask the user questions about how they would do it.
> today's best runnable-offline model is roughly 6–8 months behind today's frontier.
But it doesn't matter because frontier models were extremely good 8 months ago and we were doing real work with them. Now we have more capable open-source agents like pi and OpenCode which work well with these models.
More importantly, offline models is the best choice for privacy, on-device inference and no token/cost anxiety.
I don't understand why people crave to assign a new role for themselves (team lead, manager). AI is a tool that augments your skill and you use it carefully. It doesn't require a change in your role. A farmer with a tractor is a farmer, not a lead. An accountant with spreadsheets is an accountant. A software engineer using a coding agent is a software engineer who has a powerful tool in their toolbox.
I love the description of the PR. This type of honest statement is the right thing to do - be transparent, be respectful of the time of the reviewer.
> This PR adds support for embedded Ruby (ERB) which is commonly used in Ruby on Rails projects. Note that I used heavy assistance from Claude Code and tried to ensure it didn't generate slop to the best of my abilities. All tests are passing and I also visually verified the end result which looks solid to me.
> Here's a screenshot that was generated by building the Chroma CLI with the ERB lexer and running it against the test data file with chroma --lexer=erb --style=monokai --html lexers/testdata/erb.actual
I tried Superpowers for my current project - migrating my blog from Hugo to Astro (with AstroPaper theme). I wrote the main spec in two ways - 1) my usual method of starting with a small list of what I want in the new blog and working with the agent to expand on it, ask questions and so on (aka Collaborative Spec) and 2) asked Superpowers to write the spec and plan. I did both from the working directory of my blog's repo so that the agent has full access to the code and the content.
My findings:
1. The spec created by Superpowers was very detailed (described the specific fonts, color palette), included the exact content of config files, commit messages etc. But it missed a lot of things like analytics, RSS feed etc.
2. Superpowers wrote the spec and plan as two separate documents which was better than the collaborative method, which put both into one document.
3. Superpowers recommended an in-place migration of the blog whereas the collaborative spec suggested a parallel branch so that Hugo and Astro can co-exist until everything is stable.
And a few more difference written in [0].
In general, I liked the aspect of developing the spec through discussion rather than one-shotting it, it let me add things to the spec as I remember them. It felt like a more iterative discovery process vs. you need to get everything right the first time. That might just be a personal preference though.
At the end of this exercise, I asked Claude to review both specs in detail, it found a few things that both specs missed (SEO, rollback plan etc.) and made a final spec that consolidates everything.
This post has 500+ comments with various viewpoints and you see the summary on the right side.
You are right that most of the time threads are organized into local groups. But in the above example, there are many comments that relate to the same topic, but are not under the same parent comment. HN Companion's summary surfaces this into a topic "Limitations of Current AI Models" which shows comments from up and down the post.
You can click on the author name in that topic in the summary panel, it will take you directly to the comment. This is what we meant by "continue the conversation there", i.e you are now in the main HN experience, so you can navigate to child/parent/sibling comments (through the link buttons or keyboard navigation).
We definitely don't want AI to write comments. Happy to elaborate if you need.