Thanks for sharing. Seeing related issues and PRs seems like a useful feature. Though it would be better if the extension could somehow determine and show the
related issues and PRs to the current issue/PR, instead of listing all open tabs.
But I find the other two features to be less useful, personally. I tend to do all writing in my favorite text editor (where I'm writing this now), which is already configured with syntax highlighting, and all my editing preferences. I can save my work at any time, and always have a local copy of it. In contrast, typing in textareas is a cumbersome and risky experience no matter how friendly the UI is. One wrong click or keypress could waste minutes or hours of your time. We all have our workflow preferences, of course, but I would encourage any technical person to use their editor instead. If you don't like manually copy/pasting text back and forth, there are browser extensions that automate opening up an editor, and syncing the contents with a specific textearea.
I watched your video walkthrough, and as someone who still uses LLMs exclusively via a conversational UI, it's shocking to me that it took you 7 minutes to update the "corpus" for the LLM, and run several commands, only for the actual fix to be a single-character change in a CSS selector. Sure, the difficult thing is knowing which file and character to change, but given the issue, any developer familiar with the codebase would instinctively know where to look first, and fix the issue in a fraction of that time. Maybe even add a test case for it.
This is far from the efficiency and speed these tools were promised to deliver. Aside from the fact that you admit not having an understanding of the testing framework you vibe coded, when your entire development workflow depends on it. If this is the future of software development, as you claim, what a bleak future it is.
BTW, you have a very nice shed, Ned. :)
But I find the other two features to be less useful, personally. I tend to do all writing in my favorite text editor (where I'm writing this now), which is already configured with syntax highlighting, and all my editing preferences. I can save my work at any time, and always have a local copy of it. In contrast, typing in textareas is a cumbersome and risky experience no matter how friendly the UI is. One wrong click or keypress could waste minutes or hours of your time. We all have our workflow preferences, of course, but I would encourage any technical person to use their editor instead. If you don't like manually copy/pasting text back and forth, there are browser extensions that automate opening up an editor, and syncing the contents with a specific textearea.
I watched your video walkthrough, and as someone who still uses LLMs exclusively via a conversational UI, it's shocking to me that it took you 7 minutes to update the "corpus" for the LLM, and run several commands, only for the actual fix to be a single-character change in a CSS selector. Sure, the difficult thing is knowing which file and character to change, but given the issue, any developer familiar with the codebase would instinctively know where to look first, and fix the issue in a fraction of that time. Maybe even add a test case for it.
This is far from the efficiency and speed these tools were promised to deliver. Aside from the fact that you admit not having an understanding of the testing framework you vibe coded, when your entire development workflow depends on it. If this is the future of software development, as you claim, what a bleak future it is.
BTW, you have a very nice shed, Ned. :)