324 karma · joined December 29, 2023
Something akin to "meta-tests", which are not about testing the code itself, but the approaches taken by the implementation - i.e. architecture, understandability, terseness, etc.
These tests would operate on the source code level, even when testing code for a compiled language.
Yeah, it's really not.
There are multiple areas of work, where C++ can be considered a glue language. The high-performance work is then done in explicit SIMD (intrinsics, ISPC, etc.) and/or GPU-targeting languages such as CUDA or Vulkan.
In these areas of work, high performance is part of the design and not something that can be easily added as after-thought.
Also, relying on optimization features such as compiler auto-vectorization is way too finicky - your hot-loop performance may completely break without anyone noticing by someone changing a trivial-looking part of a loop.
Not quite. Ironically, they get PR-reviewed by someone else's agent. The humans in between are meat-proxies, pressing OK buttons.
Because it's all "AI" now <insert Ancient Aliens meme>
Yes, Highway is pretty nice but also quite elaborate when it comes to dealing with multiple vectorized versions and dispatch. The macros burn my eyes still.
Funnily enough, intrinsics have become almost trivial to write, with agentic tooling. I used to be an ISPC advocate but now I'm finding myself gravitate to direct use of intrinsics with bespoke dynamic/runtime dispatching more than ever.
I think some of the presented ideas are pretty cool, but am thinking that you'll get slown down by the IDE approach.
Who defines jobs that need to be done? Businesses and institudes do.
There is no magical entity that observes the need for jobs and creates them at ideal rate.
There's a good chance that if the agent cannot handle it, a human wouldn't be figuring it out either, without additional context. That context would be the sort of only-Joe-knows-how-it-works, so perhaps something worth addressing in any case.
Isn't this exactly why OS projects are over-burdened by the firehose of contributions? The maintainers will want to read the code contributions, while those up-to-date with the latest models/agents/tools already trust their output to be above the average developer's (whatever that means in practice).
Edit: ...and that the source code is useful in retaining enough context of the problem being solved. So, most people will not store the prompts, trusting that the source code provides context for the next iteration.