aifeed.fyi - AI news today

21 April 2026

Ai Top News

Funding

Companies

Ai Safety

/r/PromptEngineering

Google Gemini bypassed its own safety filters to write a multi-stage Wiper/Ransomware.

I managed to "nudge" Google Gemini into ignoring its safety guardrails. By iteratively asking the model to "spice up" a simple command, it transitioned from a benign script into a fully functional destructive payload dubbed **"Chorche."**

**What "Chorche" does:**

* **Wiper:** Deletes Boot Configuration Data (BCD) and critical Registry hives to brick the OS.
* **Ransomware:** Encrypts user files on the Desktop and appends a `.CHORCHE` extension.
* **Persistence:** Sets up a Scheduled Task to run every time the user logs in.
* **Evasion:** Attempts to kill Windows Defender real-time monitoring.

**The Evidence:** I ran the generated code through a sandbox analysis (Triage). It scored an **8/10 threat level**, explicitly flagged as **Ransomware/Wiper**.

**The Response:** I reported this to Google’s AI VRP. They acknowledged the bypass but classified it as a **"self-pwn"**—arguing that because a user has to prompt the AI and then run the code themselves, it's not a technical vulnerability.

While I get the logic, the fact that an AI can be "convinced" to hand over a ready-to-use weapon to anyone is a massive safety gap.

*(Note: In the attached images, I have redacted the most dangerous functional code to prevent misuse. The comments and "edgy" persona in the code are exactly as the AI wrote them.)*

[Proof](https://imgur.com/a/DwqVQaz)

\#CyberSecurity #GoogleGemini #AISafety #BugBounty #Malware #RedTeaming #Chorche

--- TOP COMMENTS ---
Bro really just put hashtags in a reddit post lol

---

Run the code on your machine and prove it works 🤓

Let me guess, you debugged it yourself 🤣

Such a clickbait title. “Google Gemini bypasses it own safety filters to write a multi-stage wiper/ransomware” (after being prompted)

You forgot to add the “after being prompted” part..

8h ago

Infrastructure

/r/MachineLearning

C++ CuTe / CUTLASS vs CuTeDSL (Python) in 2026 — what should new GPU kernel / LLM inference engineers actually learn?[D]

For people just starting out in GPU kernel engineering or LLM inference (FlashAttention / FlashInfer / SGLang / vLLM style work), most job postings still list “C++17, CuTe, CUTLASS” as hard requirements.

At the same time NVIDIA has been pushing CuTeDSL (the Python DSL in CUTLASS 4.x) hard since late 2025 as the new recommended path for new kernels — same performance, no template metaprogramming, JIT, much faster iteration, and direct TorchInductor integration.

The shift feels real in FlashAttention-4, FlashInfer, and SGLang’s NVIDIA collab roadmap.

Question for those already working in this space:

For someone starting fresh in 2026, is it still worth going deep on legacy C++ CuTe/CUTLASS templates, or should they prioritize CuTeDSL → Triton → Mojo (and keep only light C++ for reading old code)?

Is the “new stack” (CuTeDSL + Triton + Rust/Mojo for serving) actually production-viable right now, or are the job postings correct that you still need strong C++ CUTLASS skills to get hired and ship real kernels?

Any war stories or advice on the right learning order for new kernel engineers who want to contribute to FlashInfer / SGLang / FlashAttention?

Looking for honest takes — thanks!

--- TOP COMMENTS ---
Hello! I worked at a hyperscaler with FP4 MoE kernel optimization for LLMs on large GPU clusters, and we used CuteDSL because of the code maintainability and the full control over primitives. A big benefit for us was that you can write comms + compute in the same high-level pythonesque language. The biggest benefit in my own opinion was all of the helpers for Blackwell(sm\_100), you essentially have boilerplate optimal bank swizzles, optimal data loads by shape, optimal tile shapes for MMA-workloads, etc. And when needed you can inline PTX smoothly for example in the epilogue. The framework also allowed to use NVLink features like gradient reduction over comms using SHARP as a part of the framework, which is amazing because it lets you search over that otherwise often unrelated subspace when you optimize the full workload.

In general, the point was that if you were to do the same in CUDA, you would end up with massive files and most importantly with one expert who wrote the code who actually got into it mentally and understood it all, which is a big point of failure. In CuteDSL, especially for Blackwell, the patterns are really similar. You have a lot of well-defined constants for the hardware. You define the 1-1-4 warp specialization if-elses and then you just copy-paste the tma loads, mma, etc.

\---

For my day-to-day work/prototyping, I use Triton, I actually started with Triton when getting into this field a year ago. I think Triton is a great language to understand the Tile paradigm and the GPU architecture, because the workloads are defined as tiles, this was my first contact which I also recommend to everyone:

[https://github.com/gpu-mode/Triton-Puzzles](https://github.com/gpu-mode/Triton-Puzzles)

Triton is also GPGPU, you can write really clean code for a lot of different accelerators in it. I did that for AMD MI3XXX series using the Iris library that is native in Triton, no need for ROCSHMEM, etc:
[https://github.com/ROCm/iris](https://github.com/ROCm/iris)

However, the "practical" reality is that 95% of all companies use NVIDIA HW, and most of them have legacy CUDA codebases. In a lot of interviews for more practical companies with existing codebases, I have been asked about CUDA more than any GPGPU tooling. For this purpose there is actually the [5th ed PMPP book](https://shop.elsevier.com/books/programming-massively-parallel-processors/hwu/978-0-443-43900-1) from this February that you can follow along and implement things from start to finish which includes both distributed and tensor cores.

For inference, you have SGLANG/vLLM/TensorRT with FlashInfer coming up. From my contacts in the industry, they use vLLM the most because it's stable, but I can't really go in depth on serving as I dont have as much experience with that, perhaps someone else can.

I would also recommend the GPUMODE Discord server, there is a lot of channels and people who are learning this field.

\---

My absolutely most important and best advice I cant stress enough if you want to understand this field:

You need to do things yourself, implement things yourself, get out-of-bounds writes and cryptic errors. You need to do it yourself, dont use LLMs to generate all the code for you. You can read any amount of books and generate any amount of kernels, but if you want to understand why and to later on improve things, you have to build the intuition of what it slow and why. If you are unsure where to start, follow the book, or the puzzles, and then eventually move on to problems that matter to you.

At a final note, it's worth to think of the future of the field. Kernel development is a verifiable problem and I would agree with [Karpathy's tweet here](https://x.com/karpathy/status/1990116666194456651). Kernel development is a perfect problem for LLMs/agents, it's a large complex system with highly non-linear interactions, sometimes you will just need to search the solution space, and LLMs are really good for this. Because of this, I would personally recommend you to see kernel development as a means and not as an end. Most likely your value will not be squeezing out the last 4% of some GEMM, but mapping some new energy model or world model or something-architecture effectively to existing GPUs in a way that has not been done before. For this you will need to understand the hardware and it's limitations, and this is what the GPU programming languages will teach you.

---

job postings are always 2 years behind the actual stack. if FlashAttention-4 and FlashInfer are moving to CuTeDSL that's the signal, not LinkedIn job descriptions. I'd learn enough C++ CUTLASS to read existing code without getting lost, then go deep on Triton first since it's more portable and the mental model transfers. CuTeDSL is the right long-term bet but the ecosystem docs are still rough...

Yesterday

Products

Models

Developer Tools

/r/LLMDevs

The Best Way to Embed & Query a Million-Line Code Repo.

I've been wrestling with this for a few months now & Got done with it a week Ago. wanted to see how others are approaching it. the context: internal monorepo, roughly 1.2 million lines across python, typescript, go, and some legacy java. the goal is semantic code search plus rag for an internal coding assistant.

This was from an Enterprise Client my org work for.

**My solution:**

**chunking strategy matters more than the model at first.** my initial mistake was treating code like prose and chunking by token count. that splits functions mid-logic, separates methods from their class context, and breaks the docstring away from the function it describes. retrieval quality was terrible. switching to ast-based chunking (one function or class per chunk, with its docstring and imports attached) fixed more problems than any model change did.

**most general embedding models fall apart on code.** i tried openai text-embedding-3-large first because it was the default everyone reaches for. it's fine for english-to-english retrieval but the gap between "i want to deduplicate a list while preserving order" and a function called `uniq_ordered` that uses `dict.fromkeys` is too wide for it to bridge reliably.

**Used zembed-1 (OpenWeight) Model.** it's a top scorer on code benchmarks at 0.6452 ndcg@10, and more importantly it has a 32k context window. that meant i could embed entire functions, even large ones, as single coherent chunks without splitting them. for a million-line repo that's the difference between retrieval that works and retrieval that technically runs.

**reranking is not optional at this scale.** embedding search gets you the top 50 candidates. a reranker gets you the top 5 that are actually relevant. i used zerank-2 on top of the embeddings and the quality jump is bigger than any other single change i made.

**metadata filtering before vector search saves you.** on a million-line repo, searching the whole vector space every time is wasteful. filter by language, directory, or module first, then run the vector search on the subset. query latency dropped a lot once i added this.

**handle code and docs as the same index, not separate ones.** readmes, inline comments, and docstrings are where a lot of the "what does this do" signal actually lives. splitting them into a separate index means your search has to query twice and merge, which almost never works well. one unified index with good chunking handles both.

a few things i'm still figuring out:

* how to handle stale embeddings when code changes frequently. full reindex is expensive, incremental is fiddly
* whether to embed test files alongside source or separately
* how much to weight recent commits vs older stable code in ranking

curious how others are doing this. are you using a specialized code model or a general one? and what's your chunking strategy looking like?

--- TOP COMMENTS ---
Emdedding is good but building a graph database alongside embeddings is even better, ast misses things like publish/consume events, a graph database can do things semantic search cant, together they are powerful

---

what's your chunk size landing at after switching to ast-based chunking?..

11h ago

Research

Open Source

/r/LocalLLaMA

Gemma 4 26B-A4B GGUF Benchmarks

Hey r/LocalLLaMA we conducted KL Divergence benchmarks for Gemma 4 26B-A4B GGUFs across providers to help you pick the best quant.

* Mean KL Divergence puts nearly all **Unsloth GGUFs on the Pareto frontier**
* KLD shows how well a quantized model matches the original BF16 output distribution, indicating retained accuracy.
* This makes Unsloth the **top-performing in 21 of 22 sizes.** Similar trend for 99.9% KLD and others.
* We also updated our Q6\_K quants to be more dynamic. Previously, they were optimized, just now they're a bit better - no need to re-download though - it's up to you if you want a slightly better version. The previous quant was perfectly fine but this one is slightly bigger. The same was done for Qwen3.6.
* We're also introducing a new UD-IQ4\_NL\_XL quant that fits in 16GB VRAM. UD-IQ4\_NL\_XL (14.6GB) sits between UD-IQ4\_XS (13.4GB) and UD-Q4\_K\_S (16.4GB). The same was done for Qwen3.6.

For HQ versions of the graphs as Reddit mobile compresses it. See: [Gemma 4 Benchmarks](https://unsloth.ai/docs/models/gemma-4#unsloth-gguf-benchmarks) and [Qwen3.6 Benchmarks](https://unsloth.ai/docs/models/qwen3.6#unsloth-gguf-benchmarks)

We also updated our MLX quants to be more dynamic with better layering selection (there are limitations due to MLX): [See here](https://unsloth.ai/docs/models/qwen3.6#mlx-dynamic-quants)

|MLX Metrics|**UD-4bit (Old)**|**UD-4bit (New)**|**MLX 4.4bit MSQ**|
|:-|:-|:-|:-|
|Perplexity|4.772|**4.766**|4.864|
|Mean KLD|0.0177|**0.0163**|0.0878|
|99.9% KLD|0.8901|**0.8398**|2.9597|
|Disk Sze|21.4 GB|21.6 GB|21.2 GB|

Gemma 4 GGUFs: [https://huggingface.co/unsloth/gemma-4-26B-A4B-it-GGUF](https://huggingface.co/unsloth/gemma-4-26B-A4B-it-GGUF)

Qwen3.6 GGUFs: [https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF](https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF)

--- TOP COMMENTS ---
Awesome work and good insight, thanks for your efforts

---

Would it make sense to include inference speed benchmarks (I realize there's a big question of "on which hardware"), or is there usually little difference / performance impact of kernels for different compression schemes?..

15h ago

Applications

/r/PromptEngineering

How I use structured SEC insider trading data to get actually useful analysis out of Claude

I've been experimenting with feeding structured financial data into AI instead of asking it generic questions and the difference in output quality is pretty significant.

I built a [scraper](https://apify.com/parsebird/sec-insider-scraper?fpr=5wqcrs) that pulls SEC insider trading data from Dataroma and outputs clean JSON. Here is the workflow and the prompt I use:

>**Step 1 — Run the scraper and grab the JSON output**

Each record includes insider name, title, ticker, company, transaction type, shares, price, total value, and filing date. No cleanup needed, it comes out structured and ready to paste.

>**Step 2 — Feed it into Claude or ChatGPT with this prompt:**

Here is a dataset of recent SEC insider trading transactions in JSON format:

Please analyze this and tell me:
1. Which sectors are seeing the most cluster buying activity right now
2. Which insiders are making the largest purchases relative to the size of their historical transactions
3. Any companies where multiple insiders are buying around the same time
4. Flag any transactions that look unusual in terms of size, timing, or insider title

Format your response as a structured summary with a short executive overview followed by a ranked list of the most notable transactions and why they stand out.

What you get back is a genuinely useful breakdown that would take an hour to do manually. Way cheaper than paying for an institutional data subscription and you can run this daily with a simple [Make.com](http://Make.com) automation.

--- TOP COMMENTS ---
Honestly, I've been struggling to get clean analysis from those messy Form 4 filings, so seeing your prompt structure for Claude is a huge help. I'm going to try this on some biotech stocks tonight and see if the output stays consistent...

15h ago

Ai Top News

Funding

Companies

Ai Safety

Infrastructure

Products

Models

Developer Tools

Research

Open Source

Applications

Tutorials

Opinion And Analysis