"This is bad. Why haven't you fixed this yet? I would have already fixed this today with Claude code." -- Wes McKinney on radical accountability for software vendors.

#AIcodingagent #DataRenegades

Researcher spots a critical prompt‑injection flaw in Cline AI’s coding agent (Claude‑based). The bug lets attackers run arbitrary code via GitHub Actions, exposing a serious AI vulnerability. Open‑source devs should watch out and consider mitigations. Read the full breakdown to see how the exploit works and what to do next. #ClineAI #PromptInjection #AICodingAgent #Cybersecurity

🔗 https://aidailypost.com/news/hacker-exploits-cline-ai-coding-agent-vulnerability-highlighted-by

New episode of Data Renegades is live.

Scott Breitenother built a 100-person data consultancy, watched himself become the bottleneck, and rebuilt everything at Kilo Code

Their data team is one person plus four AI agents. Full conversation here:

https://youtu.be/qKFBaDWMxkk

#DataEngineering #AIAgents #AICodingAgent

Giới thiệu ayder-cli – Agent lập trình cục bộ hoạt động mượt với Ollama & Qwen3-Coder. Sử dụng XML thay JSON để tránh lỗi, chỉnh sửa tinh gọn, hỗ trợ tìm kiếm mã bằng ripgrep. Tự động xử lý task qua file Markdown, an toàn với xác nhận từng bước. Phù hợp Mac Silicon hoặc GPU mạnh. Dùng miễn phí, không lo hết token.
#AICodingAgent #Ollama #Qwen3Coder #DeveloperTools #aydercli #CôngCụLậpTrình #TríTuệNhânTạo #AIĐịaPhương #LậpTrìnhMáyHọc #CodeAssistant

https://www.reddit.com/r/LocalLLaMA/comments/

Let me try to explain what frustrates me about #AICodingAgent generated (or assisted) PRs by example. This is just one example, but it's quite typical of what I see a lot:

https://github.com/silverbulletmd/silverbullet/pull/1731

First of all: very elaborate PR description that ostensibly sounds like some deep analysis happened here. I'm not sure what the original prompt was here, but I suspect (based on some others by the same author — which I all closed) he has some "magic prompts" along the lines of "find performance bottlenecks and fix them."

And lo-and-behold, Claude found one (and probably more that are shared with yours truly in the 17 other PRs that this author opened):

"Syscalls: Reduced from 4 → 3 per write (25% reduction). This optimization is in the critical user latency path - every file save operation hits this code."

Now you will probably think: sounds reasonable, thank you!

But... is this REALLY a critical user latency path? Every file save does hit this path, but how many of those happen, really? SilverBullet is a single user app, and saves happen (with a sync lag) at most every few seconds if you're actively editing and Internet connected. Is this a path worthy of even a minute of performance optimization? I can think of hundreds that would way more interesting. But here we are.

Now this PR also adds a full benchmark suite to prove the made claims. I haven't actually looked at this code, to be honest because honestly it's pretty irrelevant because I don't feel there's a performance issue to be resolve here at all. I also haven't checked if all those stats in the PR are actually accurate. Again, doing so would take time, which I would consider 100% waste.

But here's the kicker: this PR actually introduces possibly two bugs in the ~10 lines that it actually changes: one definite bug (as I comment in the PR): it sets the creation time of a file to be the modified time, which is just wrong, but actually the only "sensible" think you can do to avoid making the syscall which this PR eliminates.

Second, more subtle, is a second bug is that it introduces a discrepancy between the OS reported file modified timestamp and the "unix clock" one, which it claims is "a few microseconds at most", but that's likely not true (and very filesystem dependent) and ANY discrepancy will mean that the sync engine breaks because it uses those last modified timestamps to check for changes.

And here's the thing. Me explaining this, thinking about it, commenting on it took likely 10x more time than the author spent on producing this piece of art. It doesn't solve an actual problem, it adds 150 lines of useless benchmarks and to top it all off introduces 2 bugs. In this case I think there's no actual way to do this properly, the PR cannot be fixed, it is just based on a wrong analysis. But in many other cases it's possible to get it to some place "good" as in: correct, but STILL it would be a waste of time, because the problem doesn't exist or at least is not worth addressing.

sigh