Open
Conversation
update AI assisted perf comment to be more accurate
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This would have to be the most pedantic comment I've ever raised, but here we are.
I love where chunkhound is headed (AST optimised memory layer is a game changer 🔥), it's just important to not misrepresent the emerging data on the impact on software development.
The "55%" figure from the quoted Github paper is misleading without considering the context:
The nature of the work has been shown to make a massive difference to the productivity impact, for example McKinsey have some solid research on the correlation between velocity and complexity - showing that gains can range from 30% to 0% depending on the work. In some cases even a negative impact on productivity has been observed, like in this 2025 study involving a group of prolific open source developers.
I wasn't sure how to reflect all this without boring everyone to death in the docs so I went for the most minimal change to make that paragraph a little bit more balanced.
In the off-chance anyone else cares about this as much as I do and would like to see it in the docs, I'd be happy to revise the section more deeply to add this context whilst keeping the optimistic outlook - maybe even a cheeky section on code quality impact and how the clever cAST parsing can be helpful in mitigating the risks?