You may want to edit the blog post, then, because that's not what it says.

The behavior of CPython and a few other implementations of Python (such as PyPy) is well documented and well understood. The semantics of the tiny subset of Python that this Python-to-eBPF compiler understands is not. For example, inferring from the fact that it statically compiles Python-ish AST to LLVM IR, you can have a rough idea that dynamic elements of Python semantics are unlikely to be compiled, but you cannot know exactly which elements without carefully reading the documentation or source code of the compiler. You can guess globals() or locals() won't work, maybe .__dict__ won't as well, but how about type() or isinstance()? You don't know without digging into the documentation (which may be lacking), because the subset of Python this compiler understands is rather arbitrary.

And also, having an LLM translate Python-ish pseudo code into C does not imply that you cannot examine it before putting it into a program. You can manually review it and make modifications as you want. It just reduces time spent compared with writing C code by hand.

LLMs can easily already write eBPF code. Try it.

bpftrace is nicer to work with and can replace bcc in most cases for debugging.

Writing it in C, compiling with clang, and loading with either C(libbpf), Go (cilium/ebpf), or Rust (Aya).

You can also write bpf in rust with Aya but i'm not sure how feature complete it is.

For very simple use cases you can just bpftrace.