Nx 23.2 ships Oxlint support, cross-worktree caching and coding agent sandbox config

Nx 23.2 introduces experimental Oxlint and Oxfmt support, offering large performance gains over ESLint and Prettier (Oxlint native rules run roughly 6.5x faster; Oxfmt shows 18-20x faster checks). Task output is now collapsed for successful/cached runs, cutting log size by up to 66x, aimed at both human readability and AI agent token efficiency. The terminal UI gains a status bar and vim-style search. Nx caching now works across worktrees, repository clones, and agent sandboxes via a shared ~/.nx directory, and a new command writes sandbox allowances for coding agents like Claude Code. Additional updates cover .NET build output caching, Angular 22.1 support, expanded Vitest generator support, Bun catalog and lockfile fixes (including a contribution from Bun's creator), selector support in nx release, and a much faster convert-to-inferred migration.

Vite 8 ships React Compiler support via Oxc with 12-15x faster transforms

VoidZero's August recap announces React Compiler support in Vite 8 via a new Oxc-based package (oxc-transform-react), replacing the Babel-based pipeline with benchmarks showing 12-15x faster transforms and 2x speedup over React's own Rust compiler port. The compiler is opt-in and lives outside Vite core. Also covered: Vite+ CLI additions (vp toolchain, vp hooks, tsup migration support, Codex CLI/Claude Code sandbox support), a Vite chunking RFC, Vitest 5 entering RC with a forked IstanbulJS coverage engine, Rolldown property mangling and faster chunk generation, Oxc minifier improvements, upcoming ViteConf and conference talks, and community projects built on the Vite/Oxc ecosystem.

Cypress 16 ships HTTP/2 support, faster typing and memory management by default

Cypress 16 targets multiple sources of slow and flaky end-to-end test suites at once. HTTP/2 support is now on by default in Chromium-based browsers, letting request-heavy pages load in parallel (a 1,000-image benchmark dropped from 3,896ms to 1,362ms). Typing defaults to 0ms delay, a faster visibility algorithm replaces the legacy ancestor-walking check, cookie and storage read commands now retry as query commands to reduce flake, and browser memory management (manageBrowserMemory) is stable and on by default to stop long runs from crashing. The release also bumps Node.js to 24, Electron to 41, and Chromium to 146, removes Cypress.env() in favor of cy.env() and Cypress.expose() for security, deprecates the Electron browser, and drops cy.exec(), cy.end(), CoffeeScript support, and older Angular/Vite/Next.js versions for component testing. A migration guide with an AI-assistant-ready prompt is provided for upgrading.

Python 3.15.0 RC2 ships as final candidate before October 1 release

<h2>Python 3.15 release candidate 2 is out</h2>
<p>Python 3.15.0 release candidate 2 is available now, and it’s the last planned RC before the final release on <strong>October 1, 2026</strong>. It includes around 144 bugfixes since RC1, and no further ABI changes are expected for the rest of the 3.15 series.</p>
<p>If you maintain a library, now is the time to test against 3.15 and publish binary wheels. The final release is close enough that anything you catch now is still fixable before it lands in users’ environments.</p>
<h2>How to test your project</h2>
<p>On GitHub Actions, you can test against the release candidate by setting <code>allow-prereleases: true</code> in your <code>actions/setup-python</code> step. Once you’ve confirmed compatibility, add the Python 3.15 Trove classifier to your package metadata.</p>
<h2>What’s new in 3.15</h2>
<p>Here’s a rundown of the major features shipping in this release:</p>
<ul>
<li><strong>Lazy imports</strong> (PEP 810) - imports are deferred until first use, which can meaningfully cut startup time for large applications</li>
<li><strong><code>frozendict</code> and <code>sentinel</code> built-in types</strong> - two commonly-requested types finally in the standard library</li>
<li><strong>Dedicated profiling package with the Tachyon sampling profiler</strong> - proper profiling support without reaching for third-party tools</li>
<li><strong>Frame pointers enabled by default</strong> - better compatibility with system profilers like <code>perf</code></li>
<li><strong>Unpacking in comprehensions</strong> - <code>[*item for item in nested]</code> now works</li>
<li><strong>UTF-8 as the default text encoding</strong> (PEP 686) - covered in detail below</li>
<li><strong>TypedDict extra items</strong> - you can now specify what happens with keys not listed in a TypedDict</li>
<li><strong>Disjoint bases in the type system</strong> - more precise type narrowing</li>
<li><strong>New <code>PyBytesWriter</code> C API</strong></li>
<li><strong>Stable ABI for free-threaded builds</strong></li>
<li><strong>JIT compiler upgrade</strong> - 8-13% performance gains depending on platform</li>
</ul>
<h2>UTF-8 as the default encoding</h2>
<p>This is probably the change most likely to affect existing code. Before 3.15, Python used the system locale to determine the default text encoding, which worked fine on Linux but caused frequent <code>UnicodeDecodeError</code> or mojibake on Windows when files weren’t in the system’s ANSI codepage.</p>
<p>Starting in 3.15, UTF-8 is the default everywhere. This affects:</p>
<ul>
<li><code>open()</code> without an explicit <code>encoding</code> argument</li>
<li><code>pathlib</code> read/write methods</li>
<li><code>gzip</code>, <code>bz2</code>, and <code>lzma</code> in text mode</li>
<li><code>subprocess</code> with <code>text=True</code></li>
<li><code>tempfile</code>, <code>configparser</code>, and <code>logging.FileHandler</code></li>
</ul>
<p><strong>If your code already passes <code>encoding</code> explicitly, nothing changes.</strong> The risk is in code that relied on the locale default and happened to work because the locale was UTF-8 anyway - that code will keep working - or code that relied on a non-UTF-8 locale, which may now break.</p>
<h3>Finding affected code</h3>
<p>Two options:</p>
<ol>
<li>Run Python with <code>-X warn_default_encoding</code> to get <code>EncodingWarning</code> wherever an encoding is being assumed</li>
<li>Use the <code>flake8-encodings</code> plugin to catch these statically</li>
</ol>
<h3>Restoring the old behavior</h3>
<p>If you need the locale-based behavior back, set <code>PYTHONUTF8=0</code> in your environment. This is a valid escape hatch for legacy systems, but the better long-term fix is to pass <code>encoding=&quot;locale&quot;</code> explicitly where you actually want locale behavior, and <code>encoding=&quot;utf-8&quot;</code> everywhere else.</p>
<h3>For library authors</h3>
<p>If your library accepts an <code>encoding</code> parameter and defaults to <code>None</code>, wrap it with <code>io.text_encoding()</code> before passing it downstream. This ensures that any <code>EncodingWarning</code> points at the caller’s code rather than your library internals.</p>
<h2>Bottom line</h2>
<p>RC2 is stable enough to test against seriously. If you haven’t run your test suite against 3.15 yet, do it now - October 1 isn’t far off.</p>


Python 3.15.0 release candidate 2 is out with roughly 144 bugfixes since RC1, and no further ABI changes are expected before the final release on October 1, 2026. Maintainers of third-party packages are urged to test against 3.15 now, publish binary wheels, and add the Python 3.15 Trove classifier. Major features include lazy imports (PEP 810), new frozendict and sentinel built-in types, a dedicated profiling package with the Tachyon sampling profiler, frame pointers enabled by default, unpacking in comprehensions, UTF-8 as the default encoding, TypedDict extra items, disjoint bases checks, a new PyBytesWriter C API, a stable ABI for free-threaded builds, and JIT compiler upgrades yielding 8-13% performance gains.

Bun 1.4 Rust rewrite faces missed deadlines, 5000 open PRs and AI-generated commits

<p>Bun 1.4 is out, and the headline is a full rewrite from Zig to Rust. The numbers are genuinely impressive: 2,900+ issues fixed, 1,517 new Node.js compatibility tests passing, idle CPU down 5x, memory usage cut up to 48% for HTTP servers, startup 50% faster on Linux. Vercel already has it in production. One user reported a 37% RPS increase on a real endpoint. Jarred Sumner says compile times are 3.4x faster than before the rewrite.</p>
<p>New built-ins include <code>Bun.Image</code> (faster than Sharp), <code>Bun.WebView</code> (headless browser without Puppeteer), <code>Bun.cron()</code>, <code>Bun.markdown</code>, and <code>Bun.Terminal</code> for PTY-backed terminal apps. Vercel’s Guillermo Rauch called it a “perfect match.” The reception from the pro-Bun crowd is warm.</p>
<p>But there’s a thread worth pulling.</p>
<p>A long-time Bun advocate published a detailed critique documenting months of missed release dates for 1.4, over 5,000 open pull requests (GitHub recommends keeping that number much lower), and heavy reliance on AI-generated commits from an automated account called “robobun.” Zig creator Andrew Kelley apparently weighed in on Bun’s code quality, and not kindly. The critic’s core question: did the Zig-to-Rust switch actually solve the memory-safety problems it was supposed to, or was it a reframe?</p>
<p>Sumner’s own tweets don’t exactly quiet those concerns. “Most of Bun’s PRs now are from things Claude found while fuzzing,” he posted. He also shared a screenshot of asking Claude which subcommands to add to 1.4. That’s either a confident bet on AI-assisted development or a preview of what happens when a small team tries to ship a runtime that competes with Node and Deno simultaneously. Probably both.</p>
<p>The performance results are real. The AI-generated PR volume is also real. Those two things can coexist, but the question of whether a production runtime can be responsibly driven by AI agents at this scale is one the community hasn’t settled. Bun 1.4 is the most prominent live test of that question right now, and 1.4.1 is already shipping Monday.</p>


Bun 1.4 has shipped with major improvements: 1,517 newly passing Node.js compatibility tests, 5x lower idle CPU, 48% less memory for HTTP servers, 50% faster Linux startup, and new APIs including Bun.Image, Bun.WebView, Bun.cron, native streams, and HTTP/2 and HTTP/3 support. Alongside the release, controversy has flared over how the runtime's underlying rewrite from Zig to Rust was executed. Bun advocate Tero Piirainen documented repeated timeline slips based on creator Jarred Sumner's own statements, questioning whether the rewrite was necessary and whether it delivered the promised memory-safety benefits. Critics also point to the project's pull request backlog exceeding 5,000 open PRs and over 15,000 commits from an automated bot account as signs of process dysfunction.

xUnit.v3 4.0.0 drops Microsoft Testing Platform v1 support

xUnit.v3 4.0.0 drops official support for Microsoft Testing Platform (MTP) v1, defaulting to MTP v2. Upgrading can break dotnet test on .NET 10 SDK with an error about VSTest no longer being supported, requiring a global.json opt-in to MTP.Microsoft.Testing.Platform. Azure DevOps pipelines using the DotNetCoreCLI@2 task also break because that task doesn't pass the new required --solution flag, so the fix is to call dotnet test --solution directly via bash instead of the task.

Tailscale and SQLite team fix 16-year-old WAL-Reset data race bug

<p>Tailscale spent months chasing ghosts in its control plane database. Random corruption, no clear trigger, no reliable repro. Turns out the culprit was a data race buried in SQLite’s Write-Ahead Logging code for at least 16 years: the WAL-Reset bug. It’s now fixed in SQLite 3.51.3, and the story of how it got found (twice, by two very different methods) is the actual interesting part here.</p>
<p>Tailscale’s side of this was brutal. They had to build a custom virtual filesystem shim just to catch the bug happening in production, plus a whole new transaction logging pipeline to even see what was going on. Working with SQLite’s core developers over months, they eventually pinned it on their own aggressive manual checkpointing setup, which was rare enough elsewhere that basically nobody had tripped over it before. Along the way the fix rollout got messy too: SQLite 3.52.0 introduced an unrelated bug involving stale expression indexes and floating-point rounding that triggered false corruption alarms, bad enough that the SQLite team pulled the release entirely.//n
Then there’s the other side of the story, and it’s the one making rounds for a different reason. One developer used Antithesis (a deterministic testing platform) paired with Claude agent skills to instrument SQLite 3.51.2 with a couple of generic invariants: no lost committed writes, no corruption. Reproduced the WAL-Reset bug in 15 minutes. Then reran against 3.51.3 and confirmed clean.</p>
<p>Months of forensic engineering versus 15 minutes with the right fuzzing setup and an AI agent writing the harness. That gap is the whole story here, and it’s worth sitting with instead of just nodding along. Tailscale’s tooling wasn’t wasted effort; it’s what let them isolate the bug in a live production system in the first place, which Antithesis-style testing can’t do after the fact. But it does raise an uncomfortable question for anyone running critical infra on top of</p>


Tailscale spent months hunting an intermittent database corruption bug in its control plane, eventually tracing it to a 16-year-old data race in SQLite's Write-Ahead Logging code, triggered by an aggressive manual checkpointing configuration. The fix, nicknamed WAL-Reset, landed in SQLite 3.51.3. A separate writeup then reproduced the same bug in 15 minutes using Antithesis's deterministic testing platform combined with Claude agent skills and a couple of generic assertions, then confirmed the fix held clean against 3.51.3. The contrast between months of manual forensic engineering and a 15-minute AI-assisted fuzzing run is presented as the real story.

Blacksmith raises $45m Series B at $550m valuation, up 10x in a year

Blacksmith, a startup providing CI infrastructure and AI-driven code testing/validation, raised a $45 million Series B led by Peak XV Partners at a $550 million valuation, up nearly 10x from its $60 million valuation less than a year ago. The company has grown from 700 to over 5,000 customers, including Mercury, Supabase, Clerk, Ashby, and Expensify, and revenue has grown more than tenfold to 'tens of millions of dollars' with a team of about 30. Blacksmith started as a CI cloud provider and has expanded into Codesmith, an AI agent that automatically fixes failed code checks, positioning itself against competitors like GitHub Actions, Cursor Automations, and cloud providers' native AI testing tools.

Google Cloud launches Developer Device Platform for mobile app testing on real and virtual devices

Google Cloud has announced the public preview of Developer Device Platform (DDP), a fully managed cloud service providing on-demand access to real physical devices and high-concurrency virtual emulators for mobile app testing. DDP offers two core APIs: Device Streaming for interactive debugging and real-time interaction with devices, and Device Run for parallel testing across hundreds of devices in CI/CD pipelines. It also introduces agentic capabilities, allowing AI coding agents to execute multi-step user journeys, detect visual artifacts, analyze chip performance, and fix hardware-specific bugs. Available from August 12, DDP uses a pay-per-minute pricing model and is positioned as an evolution of Firebase Test Lab.

Uber open-sources SubmitQueue, a speculative merge queue for large monorepos

Uber has open-sourced SubmitQueue, a high-performance speculative merge queue written in Go, designed to keep trunk branches consistently green at scale. Instead of validating changes sequentially, it speculatively rebases and validates multiple changes in parallel against predicted future HEAD states. When validations pass, changes land automatically; when they fail, SubmitQueue isolates the offending change and retries the rest without human intervention. It targets large monorepos and fast-moving teams dealing with concurrent changes and build instability. The repository includes a Gateway, Orchestrator, and MySQL backend, runnable locally via Docker Compose.