2026-07-13 · Know thine enemy: A critical engagement with AI-assisted software development

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is July 13th, 2026. Welcome back to the show. We have an interesting mix today, Fred. We are looking at the security theater of AI agents, the ethical mess of vibecoding, and some actual, honest-to-goodness systems work in libffi.

GuestI see you are starting with AI agents, Daniel. I am already bracing for the headache. The idea that we are going to solve the complexity of arbitrary code execution by making people click an allow button every thirty seconds is just adorable. It is like trying to stop a flood with a screen door.

HostWell, that is exactly the spirit we are kicking off with. Our first piece discusses how we are trapped between approval fatigue and the sheer efficiency of letting these agents run wild. The author argues that our current security models for agents are failing because they rely on human intervention that, realistically, no human can actually perform with any vigilance.

GuestIt is the ultimate farce. You cannot expect a developer to vet a complex shell pipeline or a hidden Python script in real-time. If you do, they will just reflexively click yes because they want to get back to work. It is security theater, pure and simple.

HostYou are in good company there. Over on Lobsters, a user named kornel points out that this is essentially a Vista-level security failure. They argue that if you make the human a bottleneck, the human eventually stops actually looking at what they are signing off on. But it is not just about the UI. The piece also dives into the risks of cloud-based sandboxing and repository-level access.

GuestThat is where the real fun happens. Did they mention the scoping? Everyone thinks their AI sandbox is magic until they realize it has a side-channel to their entire GitHub organization.

HostActually, that leads to a great point from the thread. Another user, simonw, mentioned having a mini-panic attack reading about those risks, but noted that the actual implementation of these proxies is often more constrained than the documentation implies. They describe a system where the agent is limited to a specific proxy that restricts it to pushing to a dedicated branch, rather than having free rein over the entire account.

GuestSure, until someone finds a way to escape that proxy or exploit the session handling. It is always a game of cat and mouse, and right now, the mouse is a generative model and the cat is a developer who just wants to finish their ticket before lunch.

HostMoving on to something that is triggering a different kind of frustration: a project called Ant. It is being marketed as a hand-built JavaScript runtime. The story making the rounds on Lobsters is that this project is heavily vibecoded, meaning it was likely generated by an LLM, and worse, it looks like it might have lifted code from other projects without proper attribution.

GuestOh, look, another person claiming they built something from scratch in a month while being fueled by nothing but sleepless nights and, presumably, a large context window. If it is vibecoded, it is not hand-built. That is like buying a box of frozen chicken nuggets, throwing them in the air-fryer, and telling people you made dinner from scratch.

HostThe community on Lobsters is certainly not buying it. A user named bendmorris did a bit of archaeology and found that the author’s claims of building this engine from scratch fall apart when you look at the source. They point out that the behavior looks like an attempt at license washing, taking existing code and re-packaging it.

GuestThe irony being that the author wrote a whole blog post about the personal sacrifice of building it. To quote bendmorris directly, when discussing the author's claim about health and sleep, they suggest the real cost was "Probably tokens?" That is the most brutal thing I have heard all week.

HostIt is a stark reminder of the tension between the speed of these new coding tools and the basic requirements of open source integrity. Our final stop today is a bit more technical. A look at performance improvements in libffi. For those who aren't familiar, libffi is a low-level library that handles function calls across different languages and architectures. The author is proposing a way to cache argument-placement metadata, which they call a plan, to speed things up without resorting to a Just-In-Time compiler.

GuestFinally, a real problem. The issue is that usually, if you want speed in an interpreter like libffi, you write code at runtime. But modern systems are rightly paranoid about memory that is both writable and executable. The W^X protection is non-negotiable. If they found a way to use a plan as a sort of bytecode cache without opening that security hole, I am interested.

HostThe thread, however, is a bit of a mixed bag. Some users, like aag, think it is a clever way to avoid JIT complexity. But others, like orib and wrl, are complaining about the provenance of the article itself. They suspect the writing, and possibly the code, is heavily influenced by Claude, to the point where they feel the text is full of fluff and misses the technical rigor they’d expect.

GuestI actually read the post. I have to agree with hailey in the thread. At one point the author talks about the x86-64 calling convention having "genuine" rules, and I am sitting there wondering what an "ungenuine" rule would look like. You cannot just vibe your arguments into registers, Daniel.

HostThe author, atgreen, actually jumped in to defend the work, noting that they made edits for clarity and emphasizing that the entire point of the plan-cache approach is to keep the W^X promise that a JIT would break.

GuestAt least they got the architecture constraints right. If you want to see how I would handle that, I would just write a static analyzer for the signature types and generate the plans at compile time for the common cases. No runtime magic, no security risk, and it would be faster than any interpreter. But that would actually require reading the ABI manual instead of asking a chatbot to summarize it.

HostAnd on that note, we will leave the bots behind for the day. Fred, are you going to spend your weekend reading ABI manuals?

GuestI have a few legacy systems to audit, which is basically the same thing but with more caffeine and fewer hallucinations. I might actually enjoy myself for once.

HostGlad to hear it. Thanks for coming on, Fred. That is all from the community over at Lobsters. We will be back tomorrow with more.