I'm confused by your answer, the previous post doesn't seem to be about vibe-coding at all.
It seems to be more about:
1. auto grouping duplicate security reports
2. auto validating if they are likely viable or likely nonsense
3. auto checking if they have recently been patched
4. auto assessing if they likely "invalide" for other reasons (e.g. they are for a very old long time no longer maintained Linux version, out of tree drivers, etc.)
I mean practically all of that isn't trivial to get working in a way appropriate for the Linux security mailing list and comes with many not so obvious complications. But also non of that is vibe coding and in most cases this is is more about AI doing a per-assemsment of send security issues to speed up the review of them, then it is about the AI doing the final decision.
At the end of the day, we would rather have a more stable and bug-free kernel than not.
It's not that much work for me anymore to report and even fix that obscure monitor driver bug that sometimes causes my machine to bootloop, unless I boot without graphics and start the XOrg server manually.
I often find myself surprised at how easily frontier models are able to find bugs across abstraction layers, that only original authors can comprehend. We need more positivity around these contributions as well.
To add to this, as long as the diff representing the removal of the driver is kept in the git history it would be trivial for someone in the far future to say to an AI agent:
"Please take this linux source and patch the Bus mouse driver back in but match the new driver interface".
With code preserved in git history it's never actually "removed". It's just, disconnected.
Sorry but I think this should be left up to the user to decide how it works and how they want to burn their tokens. Also a countdown timer is better than all of these other options you mention.
Yeah this is actually quite shocking. In my earlier uses of CC I might noodle on a problem for a while, come back and update the plan, go shower, think, give CC a new piece of advice, etc. Basically treating it like a coworker. And I thought that it was a static conversation (at least on the order of a day or so). An hour is absurd IMO and makes me want to rethink whether I want to keep my anthropic plan.
I haven't seen the associated talk, but (a) I would imagine the author chuckled while reading this, because it's sort of a joke among scholars, and (b) the point is likely focused much more on the context of presenting research (e.g., at conferences) rather than a blanket ironclad rule for all presentations you ever make ever.
While I think there's some validity to your point that the author's presentation suffers excess verbosity, I'm not too worried about it because the linked slides seem more meant to act as a reference document than an example of a good presentation, and the level of text is just fine for that purpose.
Yeah I’m the author, this was a joke. I also wanted to convey to the students in the room that this was not a high quality presentation, more so text just converted into presentation form.
There are presentations that you actually present to an audience, to which this point is valid.
But lots of presentations, including this one I think, are merely used as a means of conveying information (yeah, not my favorite way of doing so, but being a contrarian doesn't do anybody's career any good), and those are indeed intended to be read and need to have explicitly all the information that you otherwise would be speaking and addressing.
I always thought this was funny. We were taught this in grad school, but hardly anybody followed this guideline. "If there's too much text on the slide, the audience will be busy reading the slide, and not paying attention to you". I try to have just the main point on the slide, then I can talk around it. The details should be in the slide notes, if you need reminders.
Your family is starving and your dog died of radiation poisoning from the fallout but at least your local LLM can browse this and recommend a good software stack for your automated booby traps.
reply