99 karma · joined April 21, 2023
Posts and apps: https://armanckeser.com Bluesky: https://bsky.app/profile/armanckeser.com
I also know you are not really right because I was basically known as the pycharm guy in our office and cc basically immediately killed my usage and its safe to say early adopters of something like pycharm whose selling point is the easy integration will leave for agentic practices
In a few years we won't even be reviewing code. We will have abstracted code into building blocks and review those abstractions only.
If you are more conscious of the price, try out opencode or pi and research OpenRouter or similar for coding with models like GLM 5.2 or Kimi K3 or even Deepseek 4, they will be less out of the box but cheaper.
The point of the article is: there is a feature that people would like, there is someone who wants to add it, the appropriate time and a lot more for this feature to be merged has been spent yet the feature is nowhere to be found. That's the two way street I am trying to get across. I wish I wasn't even able to open the PR, I wish the maintainer would utilize more automation tools to groom feature requests and potential contributors with agreed upon plans and agreed upon timelines so that both sides time could be used much more effectively.
As far as PR descriptions etc goes, I asked multiple times what the best route to merging would be. If that went through better descriptions, I was happy to do that, as you can see, I wasn't aware of the "no conventional commits" rule, so in my next PRs I used the correct approach, but that should be completely automatable. Yes, I should have spent more time studying Jellyfin's conventions, but I shouldn't have to, not because its unfair for me, simply because there are more contributors than maintainers, so maintainers should not rely on desired behavior from contributors, they should force that behavior as much as possible.