Stacked PRs in GitHub, Gemma 4 on Mac & Kimi K3 - The Weekly Diff #8

GitHub Introduces Stacked Pull Requests

GitHub has put stacked pull requests into public preview, but what are stacked PRs exactly? A stack is an ordered set of pull requests where each layer targets the one below it, so a large change can be split into small, focused pieces without manually maintaining a pile of dependent branches.

You can create and manage stacks from GitHub.com, the GitHub CLI, the mobile app, or a coding agent using GitHub's stack skill. The CLI extension is available with:

gh extension install github/gh-stack

AI coding tools have made large changes easier to produce, which has shifted the bottleneck to review. A large generated diff still needs human understanding. Smaller dependent changes give reviewers a clearer path through the work than handing an AI reviewer an even larger diff.

Tools such as Graphite and ghstack have been making stacked changes workable for years. GitHub is integrating that workflow with the code hosting, review policies, and checks most teams already use, which removes a lot of adoption friction.

It has received strong praise, though early users reported rough edges around squash merges, re-approvals, stale local branches, and merging an entire stack. The preview currently stays within a repository, so teams that need cross-fork stacks will still need another tool.

Gemma 4 on a 2 GB Memory Budget

TurboFieldfare is a custom Swift and Metal runtime for running Gemma 4 26B-A4B on Apple Silicon Macs. It keeps roughly 2 GB of model weights and KV cache in memory, on an 8 GB Mac.

Gemma 4 uses a Mixture-of-Experts (MoE) design, where a router selects only a few specialized model modules for each token instead of running the entire model. TurboFieldfare takes advantage of that design with a shared 1.35 GB core and SSD streaming for the modules it needs. Those modules are kept in a bounded cache, and the runtime uses Metal to do the work on the GPU. The runtime's 2 GB figure covers memory usage, the complete model installation still occupies about 14.3 GB on disk.

The repository reports 5.1 to 6.3 tokens per second on an 8 GB M2 MacBook Air and 31 to 35 tokens per second on a 24 GB M5 Pro. It includes a native Mac app, a CLI, and an experimental loopback OpenAI-compatible server. The current runtime is text-only, and the server does not give tools permission to do anything automatically. A client still has to authorize and execute tool calls.

What I find interesting is the design constraint. The runtime treats the SSD as a slow extension of memory and makes the model's sparse modular design work harder. It accepts the hardware you have and redesigns the runtime around its memory hierarchy.

It would be great to know about SSD wear, sustained thermals, and how much of the result comes from techniques that ordinary memory-mapped runtimes already use. Those factors decide whether the project is suitable for daily use rather than an impressive demo.

Kimi K3's Smarter Design

Kimi K3 is a new open-weight model from Moonshot, and it is enormous. Moonshot's model card lists 2.8 trillion total parameters. Like Gemma 4, it uses a Mixture-of-Experts design, so it runs only a small slice of itself for each word, and activates 104 billion parameters at a time rather than all 2.8 trillion.

Sebastian Raschka's architecture notes walk through the changes, and the pattern behind them is a willingness to rethink areas which are otherwise known to be fixed. Some of them are about running cheaper, replacing standard building blocks with lighter versions that do the same job with less compute, while others question the defaults entirely.

The best example is the word order. Most models tag every word with a small signal that says where it sits in the sentence. Kimi K3 removes that signal and lets other parts of the model track word order on their own. That is a strange choice for a model this large, and it only works if the rest of the design carries the weight.

Moonshot reports the sparse mixture-of-experts setup is roughly 2.5 times more efficient at scaling than the previous Kimi K2, which is how a 2.8 trillion parameter model stays practical to run at all. K3 also ships with a 1-million-token context window and native support for images and video, both of which help with long coding sessions and large repositories.

It holds up on the benchmarks too. On coding and agentic tasks such as SWE-Marathon, Terminal-Bench, and BrowseComp, Kimi K3 lands in the same range as leading closed models like Claude Opus 4.8 and GPT-5.6 Sol, and edges ahead on a few.

Training a bigger model on more data is no longer the whole story, since a lot of the recent gains come from rethinking the pieces inside the model rather than only scaling them up.

Whether those swaps hold up, or how much you can trust an architecture you cannot fully reproduce, remains to be seen. The issue is, open weights let you download and fine-tune the model, though you still do not get the original training data or the exact recipe used to build it.

PGSimCity Makes PostgreSQL Look Like a Game

PGSimCity is an independent, non-commercial visualization of PostgreSQL internals in 3D. It turns processes such as the checkpointer, background writer, autovacuum, WAL writer, and client backends into a city that you can explore in the browser.

I like this kind of explanation because database internals are usually presented as a collection of boxes and arrows. A visual model gives those parts a place in your head. You may not remember every detail of MVCC after one visit, but you are more likely to remember that several background processes are constantly doing work around the query you just ran.

However, the project labels itself an early, unreviewed prototype and openly warns that its explanations may contain inaccuracies. That disclaimer is important for an educational tool about a system as subtle as PostgreSQL.

I love the idea, and the improvement I would want is to submit a query, watch it move through the system, pause it, and inspect the relevant process without having to decode a busy city first.

Vendor Lock-In of AI Sessions

"The Session You Cannot Take With You" by Earendil argues that AI providers are quietly moving the contents of your sessions onto their own servers, leaving you holding a receipt instead of the conversation.

The original inference API was easy to understand. Send input, receive output, and keep the conversation yourself. That record could be inspected, archived, replayed, or handed to another model. Modern agent APIs increasingly add provider-bound state: encrypted reasoning, hosted search results, opaque context compaction, hidden subagent messages, file and vector-store references, and response IDs that only the original provider can resolve.

The author proposes five practical tests for ownership: inspection, export, replay, audit, and deletion. Can you see what the model saw? Can you export a self-contained record? Can another implementation continue from it? Can a human explain why an action happened? Can you find and delete every server-side copy on which the session depends?

Those questions are more useful than arguing about whether a particular provider is good or bad. To debug an agent that changes the wrong file, you need to inspect the instructions, tool results, hidden summaries, and delegated tasks that led it there.

Provider-managed state is reasonable when it makes an agent faster or cheaper to continue and the user still has a readable handoff. An exportable tool log and an audit trail for subagent messages should exist alongside an encrypted fast path for the provider's own models.

If Coding Is Solved, Why Does Software Keep Getting Worse?

“Nothing Works and Everyone Is Euphoric” by Piotr Chmolowski asks why everyday products keep getting worse when coding is supposedly solved.

A banking app needs several Face ID attempts before 3D Secure appears. Slack steals focus from a terminal at exactly the wrong moment. A warranty form fails after the final step with no indication. A car interface becomes slower and less reliable after an update.

Software has grown more complex, product teams are measured on quantitative features, and bug-fixing work rarely looks exciting in a quarterly presentation. AI can make that problem worse by increasing the amount of code and the speed at which it arrives without improving what's already present.

Teams should spend some of the capacity AI creates on the work they avoid: reducing complexity, fixing old bugs, testing real user flows, and removing features that are not meant to exist.

AI models cannot tell if stability matters more than another redesign, unless the people running the project make that decision.

Organizational misalignment, distributed-system complexity, weak ownership, and bad incentives were present even before coding agents arrived. AI gives those systems a faster way to produce more of the same mistakes. The decline in quality occurs when those systems are fueled by AI even more than before.