Nobody reads every line anymore, so the question is what you check instead.

Reticle (Apache-2.0 for the SDK and engine, FSL-1.1 for the server and CLI, TypeScript, 1,267 stars, v3.7.0 last Tuesday) puts a dev-only SDK inside your web or desktop app and gives your coding agent MCP tools to click, watch and assert through it. Because it reads from inside the page, it sees what a screenshot doesn't: the request a click sent and its response, your store's state (zustand, Redux, TanStack Query, Pinia), console errors and request counts. Every check ends in yes, no or unknown with the evidence and a file:line, and only yes passes. A checked journey can be saved as a flow that replays with no model in the loop, and reticle gate fails a CI run when a change touches a flow's code without a new passing run. On Claude Code it installs as a plugin; elsewhere it's npm install -g @reticlehq/server and reticle setup mcp.

This is the thread's "check what you can count" answer, built for an agent. The README's own comparison is fair about scope: Playwright looks in from outside the browser, Reticle reads a silent 500 or a badge that disagrees with the store from inside, and it says to use both. It also lists what it can't see yet: IndexedDB, Web Workers, closed shadow roots and cross-origin iframes. The headline benchmark, 85 of 88 injected bugs caught against 59 for a Playwright script, comes from the vendor's own bug registry, though the harness is committed and reruns with one command. The Show HN post (10 points) drew six comments, all one-line questions and none from someone who had used it.

Reach for it if your agent keeps reporting fixes that you then find broken by clicking around. Delete the "now open the app and check it works" step you do by hand after every agent run. Tradeoffs: init appends to CLAUDE.md and AGENTS.md and adds a prompt-capture hook to every agent config it finds (--no-mcp and --no-prompt-capture skip them); anonymous usage counts are on by default (RETICLE_TELEMETRY=0 or DO_NOT_TRACK=1); once you link a project, captured prompts sync by default; and one author wrote 2,298 of its 2,844 commits.

KiviDB (AGPL-3.0 with a commercial license, Rust, 301 stars, v1.1.0 on Friday, 68 points on Show HN) speaks RESP2 and RESP3, so redis-cli and existing clients work unchanged. It shards keys across every core instead of running commands on one thread, persists to snapshots and an optional append-only file, and has Redis Stack-style FT.* full-text and vector search built in. Lua and TLS are build features. docker run -d -p 6380:6380 kividb/kividb starts it on 6380, so it can run next to an existing Redis. The author's numbers, on 32 Graviton3 cores with the load generator on a second machine, are 21.2 million pipelined GETs a second against 2.4 million for Redis 8.10 and 9.1 million for Dragonfly. Without pipelining Dragonfly is slightly ahead, and Dragonfly uses less memory per key (134 bytes against 177).

The author said in the thread that they "used AI a lot," for tests, refactoring and comments, and that Redis's own unit and end-to-end suites run on every change to catch breakage. That is the best answer in today's slate to the Ask HN question: you can't easily review someone's AI-assisted database, but you can check it against a test suite its author didn't write. The CI file is less firm than the comment. The redis-compat job clones Redis 8.0.0's Tcl suite, applies the project's compatibility patches, and runs with continue-on-error: true, commented as "a signal, not a gate," so a failing Redis test never fails a pull request. The benchmark Terraform is published in a separate repo so others can rerun it, and nobody had yet.

Reach for it if you run Redis or Dragonfly on a many-core box and pipelined throughput or p99 latency is your bottleneck. Delete the 32-shard Redis Cluster you run only to use all the cores. Tradeoffs: AGPL-3.0, with a CLA so the company can sell a commercial license; the Redis-compatibility run doesn't block merges, so read COMMANDS.md before assuming your commands are there; Valkey and Garnet comparisons are still promised, not published; and one author wrote 59 of 71 commits.

Gojko Adzic's boilerplate (MIT, JavaScript, 22 stars, created overnight, 14 points on Show HN) is the setup behind Votito, cut down to something you can copy. Claude Code runs in an Alpine container that shares only the workspace. A PreToolUse hook splits every Bash command into segments, unwraps timeout, xargs, env and bash -c, and allows, denies with a reason sent back to Claude, or asks you, with separate rules for each agent role. A PostToolUse hook runs eslint --fix on every JavaScript file Claude edits and blocks until the errors are gone. Its two example rules ban comments and require node: imports. An orchestrator turns a written plan into a Workflow script with parallel workers, a gate agent that runs a make target after each group, and a check agent that tries to refute what each step claimed.

The thread asked what "lights-on" meant, and Adzic's answer is the design in one line: humans supervising agents, with "controls implemented using deterministic tools, not via markdown prayers." Lint rules answer the thread's worry about agents writing their own tests. A rule you wrote once checks every edit and doesn't change its mind, and the README's advice is to have Claude add a new rule each time you find yourself giving the same review comment twice. The "around 80%" token saving is from Votito and isn't measured in this repo. Adzic also said the real setup gives agents short-lived AWS SSO tokens and test-only keys from SSM, and that this part was left out.

Reach for it if your CLAUDE.md has grown a list of rules the agent keeps breaking. Delete the "never do X" paragraphs you could write as an eslint rule or a deny pattern. Tradeoffs: the lint hook only covers .js and .mjs files; the orchestrator needs Claude Code's Workflow tool enabled; credentials handling isn't included; and it is seven commits from one author, presented as teaching material rather than a maintained tool.

Erik Kannike's qwen3-4b-deslop-v4 (Apache-2.0, released Saturday, 844 downloads of the GGUF build, 149 points on Show HN) is Qwen3-4B-Instruct with a LoRA adapter and a four-column neuron edit that remove the assistant writing habits. ollama run hf.co/erikkannike/qwen3-4b-deslop-v4-GGUF:Q4_K_M is a 2.5 GB download that runs on a laptop. On 40 prompts held out from training, the author's detector score fell from 121 to 12.5 per 1,000 words, against a human range under 15. Em dashes went from 20.5 per 1,000 words to none. It still answers 30 of 30 quiz questions and fits the requested genre and length as often as the base model.

The post is the useful part, because it shows the failures a single score would have hidden. An earlier version scored 9.9, lower than the release, and was worse. Its opinion pieces took no position, it invented a study from a real university, and it joined almost every sentence with ", which," a habit that came from the author's own teacher prompt and grew over two rounds of imitation. Fixing it took rule-based checks on whether an answer does what the prompt asked, and the released model trades a slightly higher score for task fit back at 80%. The adapter and the 175-byte neuron edit are published on their own. It is also exactly the kind of edited open weights the ProjectDiscovery post is about, so run it the way you'd run any stranger's fine-tune: for drafting, with no shell or tool access.

Reach for it if you generate placeholder copy, test data or first drafts locally and are tired of editing out the same tics. Delete the find-and-replace pass for em dashes on model output. Tradeoffs: it's a 4B model trained on 161 answers; the voice is flat and it still invents names and places; the slop detector is the author's own; and the blog's live-cursors experiment drew more early comments than the model did (now off by default).

DeepInfer (Apache-2.0, Python, 6,089 stars, repo created Friday, 585 points on HN this morning) is the inference framework behind DeepSeek's own API, released for offline inference. It runs one model, DeepSeek-V4.1-Flash (1017 is the default checkpoint), on NVIDIA SM100 GPUs or Huawei Ascend 950 NPUs. Features include DeepSeek's FlashMLA, DeepGEMM and DeepEP kernels, expert parallelism with load balancing, draft-token decoding with confidence-scheduled verification, structured output to a regex, JSON schema or EBNF grammar, and two settings this slate cares about. DEEPINFER_BATCH_INVARIANT=1 keeps results identical regardless of what else is in the batch, and with a fixed seq_seed the same input produces the same output (NVIDIA only). The README credits vLLM as the main base.

Deterministic output is what makes model behavior testable the way the Ask HN thread wants code to be. If the same prompt always gives the same answer, a changed answer is a diff you can see. The README is plain about what's missing: "a KV cache system," prefill/decode disaggregation and load balancing across replicas are "not included in this release." In the thread, a commenter argued that the KV cache system, which moves cache from GPU memory to host RAM and storage, is the part of DeepSeek's hosting advantage that wasn't released. Most of the discussion was about a translated Zhihu post putting DeepSeek's revenue at $38 per card per hour off-peak, which is revenue, not profit.

Reach for it if you already rent Blackwell nodes for V4.1 Flash and want DeepSeek's kernels and a reproducible-output mode in your evals. Delete the eval reruns you average over because the same prompt scores differently from run to run. Tradeoffs: SM100 or Ascend 950 only, with Linux, GCC 13, Python 3.12 and CUDA 13; offline inference only, so it doesn't replace a serving stack; three commits, so no public history; and the published benchmarks ran on 4 GPUs for prefill and 64 for decode.

Verification notes: star, license, creation, release, contributor and commit data are from the GitHub API on 2026-10-20; commit totals use the per_page=1 Link-header last-page count. HN points and comments are from the Algolia API. The Ask HN quotes are from HN item 50151036. The backdoor cost, trigger rates and $8 figure are from ProjectDiscovery's post of October 6. Reticle's mechanics, limits, benchmark, install footprint and telemetry are from its README; the Show HN comments are from HN item 50163896. KiviDB's features and benchmark table are from its README; the "used AI a lot" account and the claim that Redis's suites run on every change are from HN item 50152541's author replies; the continue-on-error setting is from .github/workflows/ci.yml. The factory's hooks, roles and orchestrator are from its README, REGULATOR.md, LINTER-HOOK.md and ORCHESTRATOR.md; the "markdown prayers" quote and the AWS credentials account are from HN item 50160198. The deslop figures, failed intermediate version and limitations are from the author's post; downloads and license are from the Hugging Face API. DeepInfer's features, hardware, missing components and vLLM credit are from its README; the KV-cache argument and the Zhihu revenue figure are from HN item 50163277. Pipeline health: today's pool held 84 rows, against the ~280 the compose prompt assumes. github:trending returned 9 rows across four feeds, with the go feed empty, and Reddit returned zero again, 164 days since its last nonzero day on May 9.