Vulnerabilities Found by AI Are, It Turns Out, Rarely Exploited
In the security industry, the arrival of AI-driven vulnerability discovery at scale is debated as both a blessing and a burden — but VulnCheck's tally points to a surprising conclusion. Vulnerabilities attributed to AI discovery in the first half of 2026 numbered 1,061, yet only 14 saw confirmed attacks in the wild. That puts the exploitation rate at 1.3%, the same level as the exploitation rate for vulnerabilities overall.
In other words, the data suggests that vulnerabilities found by AI are not especially likely to be targeted. There are caveats, though. The median time until exploitation has shortened from 120 days to 80, meaning that once a working exploit starts circulating, attackers can pivot to it faster than before.
And even as the volume of discoveries grows, the burden on defenders of tracking each one keeps getting heavier. Prioritization and the speed of patching look set to be tested more than ever.
Can “Not Using AI” Itself Constitute Negligence? — A UK Judge Raises the Question Head-On
The Master of the Rolls, who leads the UK's civil judiciary, raised a thought-provoking point in a speech to an association of lawyers who handle professional negligence: can not using AI itself amount to professional negligence?
The argument that mistakes made while using AI can constitute negligence is already familiar, but the possibility that “not having used it at all” could itself be questioned as negligence brings a new angle. For professions held to a “reasonable duty of care” — lawyers, doctors, consultants — it also connects to the observation that failing to use appropriate tools could, in the future, become grounds for holding professionals liable.
For now, this remains a point raised in a single speech, and no concrete case law has been presented. But the very fact that “using AI” is becoming a professional expectation as AI adoption in everyday work becomes the norm is an issue many practitioners are starting to take seriously.
Stock Market Turmoil Illuminates the Opacity of the “AI Economy”
On August 2, The Guardian ran an article that uses stock market turmoil as a thread to pull the opacity of the AI economy into focus. Centered on moves surrounding NVIDIA and China's AI industry, it argues that the reality of AI investment — booming on the surface — has in fact become harder to see from the outside.
Investment amounts and model performance benchmarks make the news every day, but “who is making money, where, and how — and what is sustainable” is hard to grasp from the outside. The market swings can be read as a moment when that opacity surfaced all at once. I'll leave the detailed analysis to the original article, but the key takeaway appears to be the structural uncertainty that resists being written off simply as an “AI bubble.”
Xberg v1: A Local Content Extraction Framework Arrives
Accurately pulling text out of PDFs, images, and all kinds of documents is a recurring bottleneck in RAG and document AI. Xberg, which arrived in this space as the successor to Kreuzberg, has now reached v1.
Its defining traits are breadth of support and performance. It covers 101 document formats and more than 367 code and data formats, transcription of audio and video, and even URL fetching including JavaScript rendering. PDF processing has been rebuilt on a Pure-Rust backend, adopting a pipeline that restores reading order with ONNX-based layout detection. Multiple OCR engines (PaddleOCR's PP-OCRv6, Tesseract, and Candle-based VLM OCR) can be switched between, and it also offers Rust-native named entity recognition (GLiNER2) and structured LLM extraction.
In benchmarks, it is reported to outperform docling and others on native PDF quality, and to lead by a wide margin on reproducing tables and reading order. It ships with 15 language bindings, and WASM and mobile inference are within its sights as well. For developers assembling document pipelines, it looks like a strong candidate.
WinterMix Quantization Runs Qwen3.5-122B Efficiently on Apple Silicon
A new quantization method for MLX (Apple Silicon) called “WinterMix” is making waves among local LLM enthusiasts. The target is Qwen3.5-122B-A10B (a MoE model), and the release is the result of benchmarking 18 quantization variants on an M5 Max (128GB) to pick the winners.
MLX has the advantage of running faster than llama.cpp on Apple Silicon, but existing quantizations below 6 bits have tended to lose accuracy. WinterMix applies sensitivity-aware mixed-precision assignment and implements GPTQ-style rounding-error compensation adapted to MLX's format, so that an 82GiB (~6-bit) build delivers higher quality than 94–95GiB 6-bit builds. It is also reported to land within 0.3–0.7% of the source GGUF. Practically speaking, it requires no custom kernels and loads straight into LM Studio and similar tools.
Especially interesting is the author's observation that differences between quantizations — indistinguishable by perplexity (a language model evaluation metric) — do show up in long-form reasoning. Even when the numbers look the same, they say, differences emerged in things like the frequency of “self-interruption” and the quality of “auditing-style re-checks” that only became clear from actually reading long reasoning traces. The weights are available under Apache 2.0.
Practical AI Coding Lessons: Separate Design from Implementation, and Beware Destructive Mutations
On Qiita, two posts collected hard-won lessons from having AI write code.
The first is an iOS app development case study. After struggling to improve the accuracy of a feature that hands images to an LLM and gets structured results back, the author landed on a workflow that spins up a “designing AI” and an “implementing AI” as separate models in separate sessions, with a human connecting the two as a “gate.” Splitting the roles, they report, kept each AI from getting lost and stabilized accuracy.
The second is a more mundane but practical account of a trap. When they had AI write code to sort a list by date in React, they ran into a bug where, inexplicably, the original state's ordering changed too. The cause was a sort that mutates the array destructively. The lesson relearned: with AI-generated code, checking “is this mutating the original data?” matters a great deal.
The common thread in both: rather than dumping everything on the AI, having humans design the structure and the boundaries ends up being the shortest path. Even as the tools get smarter, the fundamentals you need to hold down apparently don't change.