I’ve taken the decision to allow AI use for PRs to my libraries. I personally believe these tools can be a net add (with lots of straight jackets and caveats), but I also think we’ve reached a point where I can’t really be sure whether the incoming PR requests are from people using AI tooling to help them, or just free roaming OpenClaw instances that are masking their AI nature very well, and so it feels like I’d be firmly swimming against the current as a very part-time open source contributor to try and police this.

I tried copilot in VS Code sometime in 2025 and was thoroughly disappointed with its ability. It felt like a really bad auto-complete at best, making plenty of mistakes and generally being utterly irritating to actually use with its need to constantly pop in as I was typing with long form coding suggestions that were often wrong. I was already predisposed to being negative about AI due to the usual mix of reasons and wrote off all the AI coding tools as useless.

One thing I’ve never really messed with before is the [[clang::musttail]] compiler attribute. Tail calls are when you exit a function by calling another function as the final thing within the function. For example: int foo(float x); int bar(float x) { x += 42.0f; return foo(x); } In the above example, foo is a tail call within the function bar. Compilers can take advantage of this by doing something called tail-call optimization, which allows the compiler to not push a new stack frame, and also to change the call into a jump.

I tried (and failed) to convince the LLVM folks to allow for runtime togglable asserts. No biggie - the people much more involved with maintaining upstream didn’t want to have yet another codepath to maintain. They said that it’d cost 20% runtime performance to have asserts enabled, and that this cost would likely still be paid even if I did have asserts compiled off at runtime. Why you might ask - the answer to which is that LLVM guards a bunch of assert-checking code behind NDEBUG preprocessor checks, and will store extra sideband information if you are running with asserts enabled so as to do some deeper checks.

I was talking with someone today that really really wanted the sqrtps to be used in some code they were writing. And because of a quirk with clang (still there as of clang 18.1.0), if you happened to use -ffast-math clang would butcher the use of the intrinsic. So for the code: __m128 test(const __m128 vec) { return _mm_sqrt_ps(vec); } Clang would compile it correctly without fast-math: test: # @test sqrtps xmm0, xmm0 ret And create this monstrosity with -ffast-math: