Tiny JS, Geometric CPUs, and the New Agent Toolkit

The most consequential through-line in today’s batch of stories isn’t a single product launch so much as a quiet architectural pivot: software is being rebuilt around the assumption that agents will be present, persistent, and increasingly empowered. That shift is showing up everywhere—how we write frontends, where we keep state, what “developer tools” even mean, and why policy makers are suddenly treating certain kinds of markets as something closer to a national-security surface than a nerdy niche.

Start at the deceptively small end of the spectrum: µJS, billed as an approximately 5KB gzipped alternative to HTMX and Turbo, is a reminder that not every modern web problem wants a modern web stack. µJS goes after a familiar pain point—teams that like progressive enhancement and server-driven HTML, but don’t love the operational overhead of ever-growing front-end frameworks and build steps. The pitch is intentionally plain: one script tag, one mu.init() call, and you get AJAX navigation, link and form interception, and DOM fragment swapping. You can also use full HTTP verbs on any element, which nudges HTML toward becoming a richer command surface without asking developers to haul in a compile pipeline or a component framework.

What makes µJS interesting isn’t merely minimalism for minimalism’s sake; it’s the specific bundle of “small but sharp” features. It supports patch mode (multiple fragment updates per request), SSE, prefetch-on-hover, polling, and even View Transitions. It also uses idiomorph for DOM morphing, signaling that it’s not just doing blunt innerHTML swaps—it’s trying to keep UI updates smooth and structurally sane. The project is explicitly backend-agnostic, calling out PHP, Python, Go, Ruby and more, and it ships with an interactive playground plus side-by-side comparisons with HTMX/Turbo. In an era when “frontend complexity” has become a budget line item, a library like this is less a novelty and more a small pressure valve: an option for teams trying to delete code and still ship modern-feeling UX.

From tiny scripts to big ambitions: agent developer tooling is sprinting out of the lab phase and into daily workflow, and today’s sources read like dispatches from an arms race. On the build-your-own side, Andrej Karpathy has packaged “autoresearch” into a self-contained minimal repo, described as nanochat’s LLM training core stripped down to a single-GPU, single-file version of about 630 lines of code, meant for weekend experimentation. The subtext is powerful: not every meaningful agent-adjacent advance is coming from heavyweight platforms; there’s still cultural and technical momentum behind small, inspectable artifacts that individuals can iterate on quickly.

On the productized side, the center of gravity is shifting toward agents that don’t just respond—they schedule themselves. Boris Cherny’s newly released /loop frames the next step: recurring tasks for “up to 3 days at a time,” with examples like babysitting PRs, auto-fixing build issues, and spinning up a “worktree agent” when comments arrive. Another example explicitly invokes using the Slack MCP for a daily morning routine, underscoring where this is going: agent tools that live at the boundary between code and the rest of a team’s operational fabric. Once agents can schedule and re-schedule their own work, the tool you’re adopting isn’t just a chat interface; it’s a lightweight automation runtime with opinions about guardrails, permissions, and failure modes.

Distribution and openness are the other pressure points. Theo’s T3 Code is now “available for everyone to use,” described as fully open source and built on top of the Codex CLI, with an explicit promise that you can “bring your existing Codex subscription.” That “bring your own subscription” phrasing matters: it’s a bid to make agent tooling more like a client layer than a walled garden. But it also exposes the core tension in multi-vendor agent ecosystems. Theo also says they want to add Claude support via an Agent SDK so users can bring those subscriptions too—and that they have a PR ready—but they “don’t know if we’re allowed to ship it,” awaiting approval. Agent tooling is moving fast, but it’s moving on top of policy surfaces—SDK terms, vendor permissions, and runtime limits—that are not moving at the same speed. The same thread includes a usage datapoint—5,000 users already—and a rapid-fire list of fixes in a new release (markdown bullets, crashes on unsupported languages in code blocks, shell path detection beyond zsh/bash, non-git projects). In other words: this is no longer theoretical. People are running these tools against messy real-world repos, and the rough edges are becoming product work.

Where do agents put their memory, their state, the breadcrumbs that make them useful tomorrow? That question is dragging databases and filesystems back into the spotlight, and not in a “what’s the best ORM” way. SpacetimeDB 2.0 is being described (in a post noting GitHub Trending and Hacker News attention) as claiming 1000x faster than traditional databases for realtime use cases, largely by collapsing the traditional layers: it “combines the database and server,” with clients connecting directly to the database, no middle API server, and changes pushed in realtime to all clients. It’s written in Rust, with the clear implication that performance and a cohesive runtime are central to the bet.

That same impulse—collapsing layers—shows up in the parallel resurgence of filesystems as agent context. A recent note argues that teams are favoring agent-local file access and durable project state over sprawling multi-tool setups or purely ephemeral context windows, with examples like context files such as CLAUDE.md and aboutme.md. The appeal is straightforward: files are portable, durable, and easy to version alongside the work. But the story isn’t a victory lap. Early research from ETH Zürich is cited as finding that repository-level context files can lower task success while raising inference costs, a sober reminder that “more memory” is not automatically “better outcomes.” In practice, the emerging design space looks less like a single winning pattern and more like a negotiation: when should an agent read from disk, how should it search, what should be written back, and what’s the cost—in tokens and in misbehavior—of giving a model more to rummage through?

The open-source productivity world is trying to ride these same currents—ownership, extensibility, and a suspicion of locked boxes. AFFiNE is positioned as “a next-gen knowledge base” that says, pointedly, “There can be more than Notion and Miro,” and emphasizes privacy first, open-source, customizable, and “ready to use.” That combination—planning + sorting + creating, packaged as a single tool—aims at the exact territory where teams increasingly store their institutional memory, and where the stakes of control (and exportability) are highest. The GitHub listing is brief by design, but the message is clear: the next “workspace” challenger wave wants to win by defaulting to user control rather than upsell funnels.

You can also see a broader shift toward maintainable, ownable UI stacks in the attention around shadcn/ui, which has become shorthand for a community preference: curated components you can actually own and modify, rather than opaque UI dependencies. Paired with projects like AFFiNE, it signals a kind of maturation in the open-source productivity space: less emphasis on “clone the closed product” and more on “ship a coherent stack people can sustain.” Even the appearance of a project like agentjido/jido in the same neighborhood hints at how productivity apps and agent frameworks are starting to cross-pollinate, sharing primitives and expectations about extensibility.

Not every important idea arrives wearing a suit, though. Sometimes it shows up with a compass and a straightedge. CasNum is a wonderfully strange project that implements arbitrary-precision arithmetic entirely via Euclidean constructions, modeling numbers as points and building addition, multiplication, division, and even logical operations from five primitive geometric moves (lines, circles, intersections). It includes a viewer for constructions and notes on optimizations like efficient doubling and modular reduction. The demos are where the whimsy turns into a kind of technical mic drop: an RSA example, and a Game Boy emulator where the ALU opcodes were reimplemented using CasNum via minimal patching of PyBoy. It’s not pitched as a mainstream computing platform; it’s a proof-of-concept that forces you to remember that “computation” is a broader idea than “silicon + registers,” and that alternative models can be both educational and unexpectedly practical as demonstrations.

Editor tooling, meanwhile, is becoming more explicit about intent. Ki Editor argues for operating directly on the AST, putting “first-class syntax node interaction” at the center—manipulate syntax structures directly rather than relying on brittle text motions. It leans into multiple cursors and “Selection Modes” that standardize movements across words, lines, syntax nodes, and more. The promise is less about speed for its own sake and more about reducing the gap between what you mean (“wrap this expression,” “extract this function”) and what you physically do with a keyboard to make it happen.

Helix is pushing from a complementary angle: a “post-modern” terminal editor written in Rust, with Tree-sitter providing robust, error-tolerant syntax trees, and multiple selections treated as core primitives. It bundles a lot out of the box—language server support, fuzzy finding, project search, themes, auto-closing pairs, surround integration—while explicitly avoiding the usual culprits (Electron, VimScript, piles of JS) and targeting ssh/tmux workflows. It’s positioning itself as a modern alternative to Kakoune and Vim, and it even points to future ambitions like a GUI/WebGPU frontend and a plugin system. The connective tissue with everything above is hard to miss: as tools become more AST- and structure-aware, they become friendlier surfaces for agentic operations and safer refactoring, whether the “agent” is software or simply the developer in a hurry.

Finally, the policy beat: prediction markets are colliding with governance in a way that reads less like a niche regulatory squabble and more like a stress test for public trust. Senators Jeff Merkley and Amy Klobuchar have introduced the End Prediction Market Corruption Act, aimed at barring the President, Vice President, Members of Congress, and other federal elected officials from trading in prediction markets. The bill follows reports of unusually timed payouts tied to geopolitical events (including Iran strikes and Venezuelan military actions), and seeks to strengthen the CFTC’s enforcement powers and clarify rules meant to deter insider-like activity on event-contract platforms. The logic is simple: if policy decisions can move markets, and officials can trade those markets, you’ve created an incentive structure nobody wants to defend out loud.

A separate argument, focused on Polymarket, goes further and calls war prediction markets a national-security threat, citing large, well-timed crypto bets predicting attacks or leader outcomes shortly before events, and noting that Israel has charged a reservist over alleged classified-information bets. Because trades can be anonymous on-chain and probability shifts may look modest in aggregate, suspicious activity can be hard to spot in real time. Whether or not one agrees with every policy prescription, the underlying point lands: in a world of always-on markets and always-on information flow, the line between “forecasting” and “profiting from privileged knowledge” becomes both blurrier and more dangerous.

Put it all together and today’s theme is less “new gadgets” than “new defaults.” Smaller web primitives like µJS suggest teams want less ceremony. Agents want to schedule, persist, and integrate with the tools you already pay for. State is up for renegotiation—sometimes in a realtime Rust database, sometimes in plain files on disk. Open-source workspaces are trying to reclaim knowledge from closed platforms, while editors move closer to syntax-aware intent. And in the background, lawmakers are starting to treat certain forms of “collective prediction” as something that can corrode institutions—or worse—if left to run hot.

The forward-looking bet is that the next year of tooling won’t be decided by who has the most features, but by who chooses the right primitives: tiny scripts that reduce complexity, agent runtimes that can be governed, storage models that balance persistence with cost and behavior, and policy frameworks that can distinguish useful markets from perverse incentives. The builders who win will be the ones who make those primitives feel obvious—right up until you try to remove them.