← AI Hacker Daily

Edition

06

picks

# AI Hacker Daily — 2026-09-15 Every pick today opens by quoting the claim it means to disprove.

AI Hacker Daily — 2026-09-15

Every pick today opens by quoting the claim it means to disprove. Biloba's README begins with an epigraph, "Automated browser testing is slow and flaky" - every developer, ever, and then links a repository that re-runs an identical 32-scenario suite against Playwright fifteen times. Sunk Cost exists because its author "kept hearing 'just buy a Mac and run models locally, it pays for itself' and wanted to check." Droid ASC's first line is "When decompiling massive Android APKs, the standard procedure is to wait." Kinesis was built because its author "always thought it was a shame" the Meta Neural Band could not be used outside the glasses. And Atlas opens its case with "Agents now write a large share of the code and keep none of the reasoning behind it." Same rhetorical move, five times. The picks are ordered by how much of the claim actually got measured, which turns out to be a wide range.

The week's most-read number came from someone who bracketed it four separate ways. How much of F-Droid is LLM generated? went through all 102 apps in the September 12 update batch and reports 74 largely written by AI (72.5 percent), 10 hard to categorize, 18 with little to no sign. The brackets: "there's no way to effectively detect slop, so I propose a rough 3 tier system based on the aesthetics of the repo"; "I did not build a 'slop detector'"; any agentic infrastructure at all lands an app in the top tier automatically; and history is excluded by design, so an app that has existed since 2014 with recent machine-written commits counts as mostly AI. The author also states his bias in a section headed "My biases," which ends "I really hate LLMs and what they have done to programming." Read correctly, 72.5 percent is a measurement of current commit practice in one day's update batch, not of how much code in F-Droid was written by a machine. It is still a striking number, and it is more useful stated the narrow way. The observations underneath are better than the headline: four of the five Codeberg-hosted apps are rated mostly AI and therefore likely violate Codeberg's AI policy, one maintainer account ships a cluster of apps across unrelated namespaces, and Yubico's own authenticator lands in the top tier on recent commits alone.

The counterpart is a title. The weekend's best-performing technical post was Dropping eBPF CPU Cost by About 90% with Memoization(Not AI Gen), at 130 points, and that parenthetical appears nowhere in the post itself. The work is real and specific: cache which policy applies to each inode instead of walking the directory tree again, and opening the same file 200,000 times drops kernel cycles from 28 billion to 3.03 billion. The disclaimer is aimed at the audience, not documented in the artifact, which is roughly where the whole field is on provenance right now. One number on the ordering below: the pick with the most complete evidence on the desk, a reproducible comparison repository with a threats-to-validity section, drew 8 points and one comment on Show HN. The pick built in thirty-one minutes drew 116.

01

Biloba — "browser testing is slow and flaky," answered with a comparison repo that discloses a model wrote it

Biloba (MIT, Go, 27 stars, 10 forks, created March 2023, 328 commits, two human contributors, v0.16.2 shipped on September 12) is Onsi Fakhouri's browser-testing library, from the author of Ginkgo and Gomega, built on chromedp and the Chrome DevTools Protocol. Three principles, stated in CLAUDE.md and traceable through the design: performance via parallelization (one shared Chrome process, each Ginkgo parallel process driving its own isolated root tab, reused between specs rather than recreated); stability via pragmatism (a click is element.click() after synchronous, atomic visibility and enabled checks run inside the browser, not scroll-into-view plus a real pointer); and conciseness via Gomega matchers, so a spec reads Eventually(b.ByText("Sally").Within("#user-list")).Should(tab.HaveClass("online")). Specs can be written in Go with Ginkgo or in TypeScript with Vitest, off the same engine. The headline table, median of 15 runs on an M1 Max whole-suite wall clock: biloba-fast at 2.57s parallel and 9.55s serial, biloba-realistic at 3.26s and 18.60s, Playwright at 8.23s and 38.37s. Fast is roughly 3.2x parallel and 4.0x serial ahead; realistic, which routes every interaction through real CDP input the way Playwright always does, is still about 2.5x and 2.1x ahead. The fast-versus-realistic split is the same suite with one env var flipped, so only the interaction engine differs between the two runs.

The evidence repository is the reason this leads. onsi/biloba-comparison ships METHODOLOGY.md for the fairness controls and threats to validity and SCENARIOS.md for the exact workload, states that the aim is "to measure framework + runtime overhead for an identical browser-test workload — not to manufacture a win," and warns in bold that the numbers are from one machine on one day, "indicative, not universal. Run it yourself." It also opens with a disclosure most benchmark repositories would bury: "This whole comparison — harness, scenarios, charts, and write-up — was generated by Claude (Opus 4.8), working from a brief." Then the README declines to rest on it anyway: "Of course, synthetic benchmarks don't necessarily capture real-world performance," followed by two field data points. A 1,689-spec Ginkgo suite for an interaction-heavy JavaScript app completes in under 60 seconds, at a flake rate under one percent maintained by periodic local flake hunts. A mature 165-scenario Playwright suite converted to a Biloba Vitest suite went from about 3m10s to about 1m13s, "a 2.6x observed speedup" — lower than the synthetic number, and published next to it.

Reach for it if your CI's slowest job is browser tests and you already write Go with Ginkgo, or TypeScript with Vitest; it replaces Playwright Test for that suite, and it replaces nothing you pay for. Delete the nightly-only tag on your end-to-end suite, since a 32-scenario run at 2.57s belongs on every push. Tradeoffs: the comparison repository has not been pushed since June 15 and benchmarks Biloba 0.3.0, thirteen minor versions behind the September 12 release, so the headline table is three months stale against the thing it is advertising; Biloba is pre-1.0 and says so, "the public API contract may shift"; it is Ginkgo-native in Go, which means adopting Biloba means adopting Ginkgo and Gomega if you have not already; the speed comes partly from fidelity you give up, because fast mode skips scroll-into-view, occlusion checks and real pointer movement, and the honest comparison to Playwright is the realistic track; and the project is effectively two people, 259 commits and 64, across three and a half years.

github.com/onsi/biloba

02

Sunk Cost — the calculator that checks whether a local rig pays for itself, and mostly answers no

Sunk Cost takes a machine, a model, how many tokens a day you push and what you pay for electricity, and returns how long the hardware takes to pay back against renting the same model by the token. Behind it sits a data layer better than the interface suggests: 47 machines, each carrying a sources array of real citations and a power figure tagged with its own provenance. Twenty-eight of the 47 wattages are marked stand_in, 13 published, and 6 third_party_measured — and the measured ones name who measured them. The DGX Spark entry records that NVIDIA publishes no system draw, takes 150 W from a single third-party unit's peak under inference, and notes that Jeff Geerling measured 122.8 W running gpt-oss-20b; the Framework Desktop entry cites Geerling's 133 W on Llama 3.1 70B. Mac entries carry the macOS wired-memory rule with its source, llama.cpp discussion 2182, 66.7 percent of unified memory at 32 GiB or less and 75 percent above, plus the sysctl to raise it. Status fields record inconvenient facts rather than hiding them: the Spark's MSRP "raised from $3,999 to $4,699 in February 2026," the 512 GB M3 Ultra Mac Studio discontinued on August 25. Where nothing has been measured, local speed is derived from memory bandwidth and bytes read per token, "and labelled as such." The capability ratings carry their own warning: "a judgement call informed by public benchmarks, coarse on purpose."

The answer it gives is mostly no, and the 88-comment thread is where that gets stress-tested. jrflo ran it and got "43 years to break even on Qwen 3.8 at 25% the speed of the API." hyperhello's objection is structural — the labs have "astonishing amounts of compute and they're effectively dumping it on the market" — and epistasis sharpens it into the real economics: batching hundreds of concurrent streams across the same weights costs about what one stream costs, so hoarding the memory bandwidth for yourself is the wasteful configuration by construction. Then the corrections. shadowpho owns a DGX Spark: "I like this calculator but it's really wrong at least for dgx spark. I have one and I get 4x the tokens/s," which is the estimator's bandwidth heuristic meeting a real machine. And two commenters attack the machine list rather than the math. usernomdeguerre runs Qwen 3.8 at 50 tok/s on a twelve-year-old Asus with a 3090; mcone bought a used HP Omen with a 3090 for $2k and gets 57 tok/s; redox99 paid $500 each for two post-mining 3090s. They are right about the gap even though "only mac products" is not literally true — the list does include DGX Spark, Framework Desktop and Strix Halo. What it contains is 47 unified-memory boxes and zero discrete-GPU builds, which is exactly the configuration that makes the payback math work.

Reach for it before you put a Mac Studio on a company card to save on tokens; it replaces the spreadsheet you were going to build badly, and it replaces nothing you pay for. Delete the line item, in most cases, which is the useful outcome. Tradeoffs: no discrete-GPU option at all, so the cheapest real path to local inference, a used 3090 in a box you already own, cannot be entered; 28 of 47 power figures are stand-ins, which the data admits and the interface does not foreground; the estimate is memory-bandwidth-derived unless someone crowdsourced a measurement, and at least one hardware owner reports it off by 4x; the capability ratings that decide which hosted model you are compared against are the author's judgement by his own description; and the whole framing concedes its own limit, which several commenters made anyway — ProjectArcturis's "local LLMs are not really about saving money, they're about autonomy" is not a cost argument and this tool cannot price it.

sunkcost.ai/discussion ↗

03

Droid ASC — the Android decompiler that refuses to build an index, and publishes the milliseconds

Droid ASC (Apache-2.0, Python, 1,011 stars, 182 forks, created June 9, 59 commits, five contributors) is a decompiler front-end whose entire argument is that the standard preprocessing step is unnecessary. The premise: "A compiled artifact is already highly structured, modern decompilers never utilize this, they waste massive amounts of time and memory reconstructing a bloated database of code relationships over already structured data." So instead of fully inflating the APK and spending tens of minutes building global cross-reference indexes, ASC queries the compiled artifact directly as a read-only database. Three pieces of engineering carry it, and the README names each: probe inside the Deflate bitstream with dense Huffman lookup tables to pull core metadata without touching irrelevant blocks; exploit R8's deterministic constant relocation and instruction deduplication, which leave "highly concentrated physical layouts," to run cross-DEX searches against those layouts; and resolve raw bytecode offsets back to methods through an O(1) instruction-locating primitive rather than a mapping table. On a hit, it reconstructs a minimal self-consistent DEX in memory for that target alone. The CLI is three verbs — getclass, getmanifest, findrefs — plus a --gui, and the examples are the ones a researcher actually types: find every reference to the string token, find callers of onCreate in a class, dump the manifest.

The numbers are stated as a live-demo claim, which is what they are: a 352 MB commercial APK, global cross-reference searches in 1.79 seconds, target classes decompiled in 177 milliseconds, 141 MB of RAM, zero preprocessing. The venue explains the register — the README is essentially the Black Hat Europe Arsenal abstract, and the marketing verbs ("lightning fast," "we weaponize this compiler behavior") come with it. What backs it up is thinner than the prose: the benchmark is a PNG in docs/, the 352 MB APK is not named, and there is no harness in the repository to re-run any of it. The distribution caught up today. pip install droidasc works as of this morning, because version 0.1.0 was uploaded to PyPI at 09:12 UTC, the package's only release; there are no GitHub releases at all. The idea generalizes past Android, which is the reason it is here rather than in a security roundup: a compiled artifact is a structured database, and building an index over it is a choice, not a requirement.

Reach for it if you triage APKs and have ever started a jadx index and gone to make coffee; it replaces the index-then-search half of that loop, and it replaces nothing you pay for. Delete the shell alias that allocates 16 GB of heap to a decompiler. Tradeoffs: the headline figures are the author's demo against an unnamed binary, presented as an image, with nothing in the repository to reproduce them; a first-day PyPI package at 0.1.0 with no release tags is a thin supply chain for a tool you point at hostile binaries; it is a front-end, so decompilation quality is still whatever the underlying engine gives you and the win is retrieval, not output; the project is one author with 42 of 59 commits and a second contributor at 14; and the tagline sells it as "designed for Agents/Mobile Researchers," which means the fast path is being tuned for a caller that does not get tired of waiting.

github.com/MG1937/ASC

04

Kinesis — the Meta Neural Band without the glasses, from empty repo to notarized build in thirty minutes

Kinesis reads the surface EMG stream off a Meta Neural Band over Bluetooth and maps it to macOS controls: swipe between desktops, open Mission Control, control music, pinch and turn for volume or brightness, with your own mappings, a practice mode in setup, and a menu-bar item. There is a signed artifact — download the DMG, drag it to Applications, unpair the band from the Meta app first, macOS 14 or later, Apple silicon and Intel — or build it yourself with Xcode and Swift 6. The timeline is the interesting part and it is in the commit log. First commit, "native neural band controls for mac," at 11:30:36 UTC on Monday. "ship a notarized dmg" at 12:00:22. Show HN at 12:01:31. Thirty-one minutes from empty repository to notarized build to the front page, 116 points by evening, 62 stars this morning. It rests on the author's own neural-band-poc, the work of reading sEMG off the band independently of the glasses, and the Show HN says what did that work: "a couple hours ago i had astra take on a 10 month old repo of mine." Astra is GPT-6, released eleven days earlier. So the sequence is a ten-month-old dead-ended side project, a few hours of agent time to revive it, and thirty-one minutes to wrap the result in a shippable app.

The claim being disproved here has no number attached — it is just that the band is glasses-only, and the disproof is the binary. The thread supplies the constraint that matters and the author does not: easton's "Meta doesn't sell these separately from the glasses," which means the prerequisite for this tool is a purchase you cannot make on its own. geoah priced the standalone alternatives in the same thread, and the list is why this stays a curiosity for now: Mudra Link at $299, Mudra Band for Apple Watch at $350, MindRove Armband at $800, SiFi Labs' band unpriced, OYMotion gForce Pro+ at $1,250. fidotron asks the right technical question, whether the gesture set has enough fidelity and whether it needs per-person calibration, and it goes unanswered. utopiah, who works with alternative input devices, makes the durable point against the whole category: the barrier is not inertia but training requirement, because a device with "no gradient of feedback, it was either success or failure" is a much bigger investment than switching from a mouse to a trackpad. The author's own closing line is the most honest thing in the thread: "i really hope this works on other bands because the sample size has just been me so far."

Reach for it if you already own the Meta glasses and have been ignoring the better half of the hardware; it replaces nothing, which is the point, and it costs nothing. Delete the browser tab where you were pricing an EMG armband for a project you have not started. Tradeoffs: there is no LICENSE file, so the DMG and the source are all-rights-reserved by default; one contributor, nine commits, one day old, and the single pull request is the author's own; it needs Accessibility and Bluetooth permissions and asks you to unpair the band from its vendor app, which means the device stops working as Meta intends while Kinesis has it; validated on exactly one band by exactly one person, stated plainly; and the project name collides with a 34-year-old keyboard brand and an AWS service, which several commenters noted and none of them could get past.

github.com/callbacked/kinesisdiscussion ↗

05

Atlas — 4,457 stars resting on the one sentence in its README with no number behind it

Atlas (MIT, 4,457 stars, 274 forks, created May 14, 756 commits, 37 contributors with four above 60) is a Tauri desktop app that runs Claude Code, Codex, its own agent, and anything from the ACP registry side by side against one codebase, and records what each of them did. The mechanism is the checkpoint: every agent session is logged locally to .atlas/sessions.db with secrets scrubbed before anything hits disk, and when you commit — "from any tool, even with Atlas closed" — the commit is linked back to the session that produced it, with links surviving rebases and amends. You then select a checkpoint and ask it questions, and it answers from the session transcript rather than making you read it. Shared memory is the second half: a decision Claude Code made shows up in Codex's next prompt, and the markdown in .atlas/knowledge/ plus the CLAUDE.md and AGENTS.md you already wrote feed every agent in the project. The lock-in commitment is unusually specific and worth quoting: "Notes are markdown, canvases are JSON, sessions are JSONL, and the editor is a file on disk. Close Atlas and pick up in vim." The single exception is the checkpoint record, "which is SQLite in the project's gitignored .atlas/, because it is queried, not read."

Which brings us to why it is last. The case opens: "Agents now write a large share of the code and keep none of the reasoning behind it... What survives is a commit message, written by a model, summarising a diff." Nothing behind it — no study, no telemetry, no number, in a README that is otherwise precise about file formats and process boundaries. That is the same move the picks above make and the only one where the measurement never arrives, in the project with by far the most stars. This is also worth noting about the trending feed that surfaced it: Atlas appeared as a TypeScript repository in August, as a Rust repository on September 3, and in the all-languages list today, having changed nothing — it is 5.16 MB of Rust and 4.86 MB of TypeScript, and whichever side of a Tauri app is growing that week decides its label. Two disclosures the README makes and a reader should weigh: Atlas Agent, the native one, "runs in-process on a hard fork of the Codex engine," and the supported platform is macOS only, with Linux and Windows building from the same codebase but "untested."

Reach for it if you run two or three different coding agents against the same repository and have ever tried to work out, months later, why a file looks the way it does; it replaces the scrollback buffer, and it replaces nothing you pay for unless you want team sync. Delete the habit of pasting the plan back into the next agent's opening prompt. Tradeoffs: the latest release is alpha-0.3.1, which is the maturity level the version string claims and should be believed; macOS only in practice, and there is not even a Homebrew tap yet — the README carries a #todo comment wishing for one — so installation is a DMG from a website; running your agents inside someone else's window means a Tauri app now sits between you and the tools you already trust; the native agent being a hard fork of Codex means you inherit a fork's divergence on top of that; and a tool built to preserve provenance opens by asserting a fact about provenance that it does not source.

github.com/pacifio/atlas

06

Also on the desk. BrewUI (AGPL-3.0, 1,034 stars, 1,079 commits, v0.4.1 on Monday, 388 stars in the last day) is Homebrew's official macOS GUI, installable with brew install --cask homebrew-app, built in SwiftUI with Swift 6 strict concurrency against the brew CLI and the Homebrew JSON API, for "CLI-averse users" and written to "never hide what Homebrew is doing." Two caveats worth the footer: it requires macOS Tahoe 26 or later, and the licence is AGPL with the network-use clause, which the README flags itself. Alternatives to MinIO for single-node local S3 (59 points, a January post resurfacing today) is Robin Moffatt working the problem after MinIO's owner "decided to abandon it to pursue other commercial interests," and it is a genuine verdict rather than a listicle: SeaweedFS yes, S3Proxy yes, RustFS "maybe, but very new project & alpha release," CloudServer "yes, maybe? Honestly, put off by it being part of a suite," Garage "no, config too complex for what I need," Apache Ozone "lol no." The stated scope is the simplest single-node S3 for a Docker Compose demo, not production object storage. Pelican-bicycle alternatives (123 points) re-runs an experiment nine months on: thirty Simon Willison-style SVG prompts given to then-current models in late 2025, ten of them repeated through six models at OpenRouter this weekend for about twenty dollars. Cheap, dated, repeatable — three properties most published evals lack.

Verification notes: star, fork, commit, contributor, licence, release, language-byte and creation figures are from the GitHub API on 2026-09-15; commit counts use the per_page=1 Link-header page trick (biloba 328, ASC 59, atlas 756, BrewUI 1,079, kinesis 9). HN points, comments, timestamps and all quoted comment text are the Algolia API (/items/<id> for full trees). Every quoted sentence was re-read from its raw source rather than a summary: READMEs and CLAUDE.md via raw.githubusercontent.com and the contents API, the F-Droid piece from the fetched HTML (the 74/10/18 split and the three-tier criteria are the author's own words), the eBPF figures from the post. Sunk Cost's machine table was read from its JavaScript bundle (/assets/index-DryDkaUl.js): 47 machines across Mac Studio 14, Mac mini 12, Strix Halo 10, MacBook Pro 8, MacBook Air 2, DGX Spark 1, with load_watts_status counts of stand_in 28, published 13, third_party_measured 6, and zero matches for RTX, GeForce, 3090, 4090 or 5090 anywhere in the bundle. droidasc's PyPI record shows exactly one release, 0.1.0, uploaded 2026-09-15T09:12:10, requires Python 3.10 or later, licence field empty. Kinesis commit timestamps are UTC from the commits endpoint; the Show HN was posted at 12:01:31 UTC, 61 seconds after the notarized-DMG commit, and the sole pull request is authored by the repository owner. The identification of "astra" as GPT-6 Astra (released 2026-09-03) is from a web search, not from the author, who wrote only "astra". Biloba's headline table and both real-world data points are the README on master; the comparison repository's last push is 2026-06-15T22:48:38Z and its text names Biloba 0.3.0. Nothing was installed or run: four of five picks need hardware or an OS this desk does not have (a Meta Neural Band, macOS for Kinesis, Atlas and BrewUI) or a target binary it should not go looking for. Reddit returned zero rows for the twenty-eighth consecutive week, and github:trending returned 8 rows across its all, go and python feeds with rust and typescript empty; all five picks came from hn:show and github trending, and Product Hunt's 26 rows contributed nothing.

One of these,
every weekday.

Free. Unsubscribe by replying with one word. No tracking pixels in the email.