Hm, this leaves me with a lot of question marks. The View demo button apparently does nothing. Privacy, Terms, and Contact just scroll to the top of the page again, nothing else. And nothing on the page explains what that tool does better than a good set of AI rules and skills in your own project, which should be able to perform such scans just as well (likely better as they know your project context). Or am I missing anything?
I place a lot of importance in my own projects that every agent session captures non-obvious learnings as rules and that skills learn from their executions. Interesting approach to bring this fully local! A bit unfortunate that the RAM requirements will lock some Macs out, but I guess that's not easily changeable right now.
So How do you prevent the continuously fine-tunes itself from drifting away from its original capabilities? The idea of training LoRA adapters from user corrections is interesting, and how do you balance personalization vs. catastrophic forgetting?
Well, when fine tuning it doesn't do it as one big adapter. It works like skills it learns a new skill and that becomes an adapter, that is then tested against a golden file that tests its core skills as well as the skills the ai wants to know and if it fails to complete the essential skills than the adapter gets dropped and the new training data considers the gaps in its capabilities.
Well, yeah it is fully local. Unless you want to bring in an MCP server from a frontier AI model to explain and give the solution (but that is in a heavy work in process). Thanks for the feedback and yeah the ram do lock some macs out!
Interesting. As someone who's not that experienced when it comes to interacting with large open-source projects, I can't say much about how this protects against being flooded with no-effort PRs by bots/people not really interested in contributing. If it does, then sure, this is understandable.
Also, I assume that the license question played a big part in this; and again, this is understandable then.
However, I do feel that this policy is unrealistic in this day and age when it comes to your valued contributors. With software development being changed so much through AI, telling your contributors that they may not use AI to write the code they want to contribute feels off.
If this is only meant as "we know you'll be using AI to generate the code anyway, and that's fine; we just have to write it in the policy to protect against flooding and licensing issues", I would find that very dishonest.
I can very much relate to the experiences described in the article. In my projects, I have multiple Claude skills and rules aiming at making my files (the code, but also the Claude files themselves) more token-effective. I have seen huge differences in token usage before and after invoking those skills, which I regularly do as part of having Claude audit my projects; although I haven't measured them. Those projects are (like the one in the article) fully developed by Claude Code, so I found such audits and mindful token usage very necessary.
