Security-related code should be readable and auditable.
I have a strong feeling that this person just likes this as a style and enforces it by hand…
Models have gotten good, but c'mon. Good idea, maybe even a good implementation, but I don't have confidence in it, and you've got to have confidence in a project that claims to provide security.
Also, even the best models still regularly write C security bugs. It doesn't make sense to have a model write C code when having it write in a memory safe language is only slightly more effort/cost.
And, it's not my monkey. You can inspect the code, build a verification pipeline for it, use agents to explore the architecture and see if you can unearth anything fowl.
My heuristic is to dismiss purely vibe-coded apps from people I don't know, particularly for security sensitive stuff. If the README is written by a human and is coherent and exhibits some kind of desire and competence to make good software on the part of the author, I'm more likely to trust they drove their agents with care.
Here's the thing: you can make good software with agents, if you exhibit good judgement and put yourself in the path as a gate on quality. Too many clues point at this being loop engineering. And, C for this task, given 100% agent authorship, gives me the ick. Seems like bad judgement or opting out of making judgement calls.
> It is designed for CI pipelines, CTF jail challenges, and lightweight code evaluation
Looking at the list, it seems pretty good for that. What does a CI runner that just needs to run GCC or whatever really need?
Edit: no open does seem restrictive. Not that it's bad security (not my area of expertise), but how many useful programs use open that are just off limits here?
It looks suspicious, even if it isn't. All those empty commits look like an intentional obfuscation of something, though I have no idea what.