Hacker News
Daily AI Digest

AI Submissions for Fri Jan 02 2026

TinyTinyTPU: 2×2 systolic-array TPU-style matrix-multiply unit deployed on FPGA

Submission URL | 122 points | by Xenograph | 50 comments

TinyTinyTPU: a bite-size, working TPU you can simulate and run on a Basys3 FPGA. It implements a full TPU-style pipeline around a 2×2 systolic array, making TPU internals tangible for learning and experimentation.

Highlights

• End-to-end design: 2×2 systolic array (4 PEs) plus accumulator, activation (ReLU), normalization, and quantization stages
• Works today on a low-cost Basys3 (Artix-7) board via a simple UART host interface and Python driver
• Multi-layer MLP inference with double-buffered activations; includes demos (e.g., a mouse-gesture classifier)
• Thorough test suite with cocotb + Verilator and optional waveforms; module and top-level coverage
• Open-source flow supported (Yosys + nextpnr) in addition to Xilinx Vivado

Architecture notes

• Systolic dataflow: activations move horizontally; partial sums vertically
• Diagonal wavefront weight loading to align systolic timing
• Weight FIFO → MMU → Accumulator → Activation → Normalization → Quantization pipeline
• UART protocol for commands/results; 115200 8N1

Resource footprint on Basys3 (XC7A35T)

• ~1k LUTs (≈5%), ~1k FFs (≈3%), 8 DSP48E1 slices, 10–15 BRAMs, ~25k gates
• 100 MHz clock; reset on BTNC; RX/TX on B18/A18

Developer experience

• Sim: Verilator 5.x, cocotb, GTKWave/Surfer; make targets for unit and integration tests with waveforms
• FPGA: Vivado or Yosys/nextpnr build; Python host scripts for loading weights/activations and reading results
• Clear, modular repo with DEBUGGING_GUIDE and per-module tests (PE, MMU, accumulator, activation pipeline, UART, full system)

Why it’s interesting

• A minimal yet complete TPU you can read, simulate, and tinker with—ideal for understanding systolic arrays, post-MAC pipelines, and hardware-software co-design
• Demonstrates how a TPU scales: this 2×2 version is educational; the same concepts underpin larger arrays like TPU v1’s 256×256

Try it

• Run all sims from sim/ with make test (WAVES=1 for traces)
• Flash to Basys3 and use the provided Python driver to push weights/activations and execute inference
• Optional gesture demo trains a 2-layer MLP and performs real-time classification on the FPGA

While the submission focuses on an educational TPU implementation, the discussion broadens into a debate on the future of AI hardware, specifically comparing FPGAs, GPUs, and ASICs in the context of large-scale inference.

The Evolution of AI Hardware

• The Crypto Analogy: User mrntrwb likens the trajectory of AI inference to Bitcoin mining: moving from CPUs to GPUs, briefly to FPGAs, and finally to ASICs. They predict that GPU-based inference will soon become obsolete due to inefficiency compared to purpose-built chips (like Google's TPU or Groq).
• The Counter-Argument: Others, including fblstr and ssvrk, argue that modern Data Center GPUs are already effectively ASICs given the amount of die area dedicated to fixed-function matrix multiplication (Tensor Cores) rather than graphics. NitpickLawyer notes that high-end accelerators are much closer to ASICs than traditional video cards.

FPGAs vs. GPUs for Inference

• Performance Claims: A heated debate emerged regarding whether FPGAs can compete with top-tier GPUs (H200/B200). User dntcs claims to have worked on FPGA systems that outperform H200s on Llama3-class models, largely by bypassing memory bottlenecks.
• Skepticism: fblstr challenges this, noting that while memory bandwidth is the bottleneck, the sheer compute density (PetaOPS) of chips like the Blackwell B200 is difficult for general-purpose FPGA fabric to match.
• Bandwidth is King: Multiple users (tcnk, bee_rider) agree that the real constraint for inference is memory fabric and bandwidth. tcnk highlights modern platforms like the Alveo V80 with PCIe 5.0 and 200G NICs as the current state-of-the-art for programmable in-network compute.

Market Dynamics

• Hyperscaler Custom Silicon: The discussion notes that major tech companies (Google, Amazon, Meta, Microsoft) effectively already use custom silicon (TPUs, Inferentia, Maia) for their internal workloads, reducing reliance on Nvidia for inference.
• Edge Hardware: Narew and mffklst briefly discuss older "stick" format TPUs (Google Coral, Intel compute sticks), noting they are now dated and struggle to compete with low-power GPU/SOC options like Jetson.

Other Technical Notes

• 0-_-0 and hnkly drew parallels between neural networks and CPU branch predictors, discussing the potential for AI to handle heuristic tasks (like speculative execution) to skip expensive deterministic computations.
• zhm clarified that while TPUs are often associated with Transformers, architectures like the TPUv5 (Ironwood) were designed specifically for efficient LLM training, whereas other chips (like Etched's Sohu) are true Transformer-specific ASICs.

AB316: No AI Scapegoating Allowed

Submission URL | 36 points | by forthwall | 19 comments

California’s AB316, as described by the poster, adds Civil Code 1714.46 and bars “the AI did it” as a liability defense: if an AI system causes harm, developers or users can’t claim autonomy as a shield. The law broadly defines AI as systems that infer from inputs to generate outputs affecting physical or virtual environments.

The author (not a lawyer) thinks this is reasonable but vague, and raises thorny questions about who’s on the hook when things go wrong:

• Where does liability sit between model makers (e.g., OpenAI), app builders, and deployers?
• How does this play with open-source models used in critical contexts (e.g., an aircraft system)?
• Will claims hinge on marketing representations or integration choices?

Expected knock-on effects: more investment in guardrails and safety layers, tighter operational controls, stronger contracts and indemnities, and a budding market for AI liability insurance. The takeaway: unpredictability won’t excuse harm; if your system can cause damage—like a chatbot giving dangerous advice—you’re responsible for preventing it.

Discussion Summary:

Commenters grappled with the boundaries of liability, using analogies ranging from food safety to science fiction to explore whether unpredictability should absolve developers of blame.

• The "Eggshell Skull" Doctrine: The discussion opened with a grim hypothetical: if a chatbot encourages a user to commit suicide, is the developer liable? While some users felt a bot shouldn't be held to the same standard as a human, others cited the "eggshell skull" legal rule. This doctrine suggests a defendant is liable for the resulting harm even if the victim had a pre-existing vulnerability (like suicidal ideation), implying developers cannot use a user's mental state to shield themselves from the consequences of a bot's "persuasive" errors.
• The Zoo Analogy: One user reframed the AB316 logic using a zoo comparison. The law essentially states that "the AI is a wild animal" is not a valid defense. Just as a zoo is responsible for containment regardless of a tiger's natural instincts, an AI deployer is responsible for the system's output, regardless of its inherent unpredictability.
• Product Liability Parallels: Participants drew comparisons to the Jack in the Box E. coli outbreaks and faulty car parts. The consensus leaned toward treating AI as a commercial product: if a company sells "sausages made from unsanitary sources" (or a model trained on toxic data), they face strict liability for the outcomes.
• Redundancy vs. Clarity: A debate emerged over whether this law is redundant, given that product liability laws already exist. However, proponents argued the legislation is necessary to specifically close the "autonomy loophole," preventing defendants from claiming a system's "black box" nature puts its actions outside their legal control.
• The "Catbox" Sophistry: In a philosophical turn, a user cited the "Schrödinger's Catbox" from the novel Endymion—a device where a death is triggered by random radioactive decay, purportedly absolving the user of murder. The commenter argued that corporate reliance on AI stochasticity is a similar moral sophistry, attempting to use randomness to dilute ethical responsibility.

Everyone's Watching Stocks. The Real Bubble Is AI Debt

Submission URL | 48 points | by zerosizedweasle | 27 comments

Howard Marks flags rising leverage behind the AI boom as a late‑cycle warning sign

• The Oaktree co-founder says the AI trade has shifted from being funded by Big Tech’s cash piles to being increasingly financed with debt, a change he finds worrisome.
• He argues the AI rally looks further along than earlier in the year, with growing leverage a classic sign of maturing (and potentially bubbly) markets.
• Why it matters: Debt magnifies both gains and losses. If AI-driven revenues don’t arrive fast enough to cover swelling capex and financing costs, the pain could spread from equity to credit markets.
• What to watch: Hyperscalers’ capex and borrowing trends, off-balance-sheet commitments (long-term purchase and leasing deals), and credit spreads tied to the AI supply chain and data-center buildout.
• Context: Marks’ latest memo (“Is It a Bubble?”) doesn’t call a top outright but underscores that the risk profile of the AI trade has changed as leverage enters the picture.

Daily Digest: Hacker News Discussion

Investment Strategy Amidst "Doom" Signals The thread opened with users questioning where to allocate capital given the economic warnings (bubbles, debt, and inflation). Responses ranged from adhering to standard long-term strategies (such as Vanguard's 80/20 split) to fleeing to safety. While some advocated for holding cash to avoid potential market crashes of 15%+, others argued that cash is a poor hedge during inflationary periods driven by potential government "money printing." There was also a brief, contentious suggestion to pivot toward specific foreign indices (like Spain) or gold as safety plays.

Historical Parallels and Timing Highlighting the difficulty of acting on macro warnings, one commenter pointed to the Dot-com era: Alan Greenspan famously warned of "irrational exuberance" in 1996, yet the bubble did not burst for several more years. The consensus suggested that while valuations may be unsupported, timing the exact top remains notorious difficult.

Validating the Leverage Shift Validating the article's core thesis, a user shared their own analysis of Big Tech balance sheets (specifically Meta, Microsoft, and Amazon). They noted a distinct shift starting around the release of ChatGPT in late 2022: these previously cash-rich "fangs" have significantly increased their debt loads to finance the AI buildout, a fundamental change in risk profile that led the user to exit a 10-year position in the sector.

AI Submissions for Thu Jan 01 2026

Build a Deep Learning Library

Submission URL | 120 points | by butanyways | 15 comments

Build a Deep Learning Library from Scratch (free online book)

• Learn by building: start with a blank file and NumPy, implement your own autograd engine and a small suite of layer modules.
• By the end, you’ll train models on MNIST, plus a simple CNN and a simple ResNet—gaining a clear, under‑the‑hood understanding of modern DL stacks.
• Free to read online; pay‑what‑you‑want support via Gumroad. Questions/feedback: zekcrates@proton.me.

Discussion Summary:

• Community Implementations: The comment section became a showcase for "learning by doing," with multiple users sharing their own custom ML libraries built from scratch in both Python and C++. One notable mention included a user who successfully replicated GPT-2 using their own NumPy-based library.
• Comparison to Karpathy: When asked how this compares to Andrej Karpathy’s "Zero to Hero" series, the author explained that while Karpathy’s Micrograd operates on scalars, this book focuses on tensors. However, the author still recommended Karpathy’s videos as a complementary resource.
• Depth of Abstraction: Some technical discussion arose regarding the use of NumPy. Critics argued that relying on NumPy hides the implementation details of tensors themselves; the author agreed, suggesting a future C++ backend might address this, while others expressed interest in a "build NumPy from scratch" guide to cover that gap.

Building an internal agent: Code-driven vs. LLM-driven workflows

Submission URL | 67 points | by pavel_lishin | 31 comments

TL;DR: LLMs plus tools can automate complex internal workflows, but tiny error rates can break trust. Imprint now treats LLM orchestration as the fast default and “graduates” important workflows to deterministic, code-driven coordinators.

The story:

• Problem: An LLM agent auto-tagged Slack messages with :merged: by parsing PR links and checking GitHub. It worked great—until it occasionally marked unmerged PRs as merged, causing real risk (people stopped looking).
• Lesson: Determinism matters. A 1% error on internal ops can erase 99% of the value.

What they built:

• Two coordinators in the same framework:
  • coordinator: llm (default) — LLM selects and sequences tools; handler enforces limits and termination.
  • coordinator: script — a checked-in Python script gets the same tools, triggers, and “virtual files” (Slack/Jira attachments). It can optionally invoke a subagent LLM for specific steps, but control is explicit and reviewable.
• Engineers can one-shot convert working prompts into code (via Claude Code), preserving behavior while gaining reliability, speed, and code review.

Why it matters:

• Hybrid pattern: start with LLMs for exploration and simple cases; promote to code when you need guarantees on correctness, latency, or cost.
• Even as models improve, use LLMs narrowly for truly intelligent decisions; handle iterative, stateful orchestration with deterministic software.
• Framing: “progressive enhancement” for agents—LLM when sufficient, code when necessary.

Determinism, Evals, and the "Script vs. Agent" Debate

The discussion around Will Larson's post focused heavily on the engineering trade-offs between probabilistic LLMs and deterministic code for internal tooling.

• Skepticism on LLM Necessity: Many commenters questioned the premise of using an LLM for tasks with established APIs (like checking GitHub PR status). The consensus among skeptics was that if a deterministic API exists, wrapping it in an LLM introduces unnecessary cost, latency, and "judgment" errors into what should be a binary operation.
• The Struggle with Non-Determinism: A significant portion of the thread debated why LLMs cannot be perfectly deterministic even with temperature=0. Technical explanations cited floating-point non-determinism in GPUs and batching variances. This unpredictability frustrates iterative development, where small changes to a "spec" (prompt) can result in a completely rewritten, broken solution rather than a slight modification.
• "Evals" are the New Unit Tests: To mitigate hallucinations, commenters suggested treating LLM outputs as untrusted candidates that must pass rigid, deterministic tests (Evals). For example, rather than trusting the LLM to check a PR, the LLM should write the code to check the PR, which is then verified against a mock environment.
• Defining the Boundary: Users argued that the "Code vs. LLM" framing is slightly misleading. The emerging best practice is using LLMs for intent understanding and handling unexpected states (e.g., messy HTML, vague user requests), while handing off the mechanical execution to standard code.
• Security Risks: A smaller sub-thread highlighted the danger of "prompt injection" in internal agents, noting that an agent with broad permissions (reading Slack, checking GitHub) is a high-value target for malicious input manipulation.

Hierarchical Navigable Small World (HNSW) in PHP

Submission URL | 91 points | by centamiv | 15 comments

HNSW in PHP: fast vector search without scanning everything

• The problem: Doing cosine similarity against every vector is linear-time and crawls at scale (think scanning 10M docs one by one).
• The idea: Implement HNSW (Hierarchical Navigable Small World) in PHP—a layered graph where upper levels act like “highways” and lower levels like “side streets,” letting you zoom toward the target quickly.
• How it works:
  • Greedy descent from the highest layer to Level 1: at each layer, hop to neighbors that improve similarity until no improvement, then drop a layer.
  • Precision pass at Level 0: run a best-first search with a priority queue. The ef parameter controls the candidate set size (bigger ef = higher recall, slower). M controls max connections per node (bigger M = more memory, better recall).
• Implementation notes: Uses cosine similarity, SplPriorityQueue, and a winners list to track top results; part of an open-source PHP project called Vektor for native vector search.
• Why it matters: Brings ANN-style speedups to pure PHP—no external services—while exposing clear speed/accuracy/memory trade-offs via ef and M.

Takeaway: If you’re doing semantic search in PHP, HNSW gives you near-instant queries with tunable precision instead of O(N) scans.

Here is a summary of the discussion:

The author, cntmv, joined the comments to explain their motivation: they wanted to deeply understand HNSW mechanics without determining them via external libraries, noting that modern PHP (8.x/JIT) is surprisingly capable of handling this workload. They positioned the library as a "drop-in solution" for PHP monoliths to add semantic search without managing external services like Qdrant or Pinecone.

Key discussion points included:

• Practical Use Cases: User hu3 asked about the feasibility of indexing 1,000–10,000 Markdown or PHP files for an LLM agent. The author confirmed the library handles 1,000 documents with millisecond search times, though they advised careful chunking when parsing code snippets.
• Dependency Confusion: User Random09 pointed out that the examples seemed to require OpenAI. The author clarified that the library is completely model-agnostic (compatible with Ollama, HuggingFace, etc.) but agreed to update the README, as the current "Hello World" example relies on OpenAI for convenience.
• Educational Value: Several users praised the blog post's clarity, highlighting the use of "fantasy-based examples" (comparing programming to magic incantations) and the implementation itself, which fthsx described as creating "executable pseudocode" that makes complex algorithms easier to understand than lower-level implementations.

Cycling Game (Mini Neural Net Demo)

Submission URL | 21 points | by ungreased0675 | 3 comments

Cycling Neuroevolution is a slick, interactive demo where a pack of identical cyclists are controlled by tiny neural nets that evolve race-by-race to get faster over a 2 km course with randomized terrain. You can watch tactics emerge—push on climbs, recover on descents, drafting trains, late sprinters—as selection and small weight mutations hone their behavior.

Highlights

• How it works: Each rider’s neural net takes in speed, current power, battery level (W′), short- and long-horizon gradient, gap to the rider ahead, and race progress; it outputs a per-timestep change in power (scaled by a Power Multiplier). After each race, the top 5 riders are kept; the next generation mixes exact copies with mutants (σ=1.0, 20 weights mutated).
• Physics/physiology: 87 kg rider+bike, CwA 0.32, Cr 0.004; drafting cuts drag by up to ~40%. Aerobic threshold 250 W, W′ 15 kJ that drains above threshold and recovers below; max sprint 750 W, tapering with battery state.
• What you can do: Click a rider to inspect their controller; red/blue inputs show real-time positive/negative contributions. Press space to force evolution mid-race, ‘r’ to reset the top-5 view, reload for fresh terrain and new populations.

Why it’s neat

• It’s an approachable, visual primer on neuroevolution with interpretable signals and believable cycling dynamics, showing how simple controllers plus selection pressure can yield lifelike race strategy.

By Andrew Davison (Imperial College London, 2025) — @ajddavison for ideas/suggestions.

Discussion Summary: Commenters scrutinized the neural network's inputs, appreciating how separate moving averages for gradients (100m vs. 1000m) allow agents to distinguish between short rollers and sustained climbs. There was also a technical debate regarding sprint behaviors: while one user suggested a dedicated "distance to finish" input to trigger end-game bursts, another argued that the existing race progress metric should sufficiently handle late-race strategy.

Show HN: A local-first financial auditor using IBM Granite, MCP, and SQLite

Submission URL | 19 points | by simplynd | 3 comments

expense-ai is an open-source, local-first “Senior Auditor” for personal finance that turns raw bank statements into verified insights using the Model Context Protocol. Running entirely on your machine via Ollama, it pairs two Granite models (8B for reasoning, 2B for vendor normalization) with a FastAPI backend, an MCP server exposing SQLite tools, and a React dashboard. The LLM orchestrates SQL-backed queries to guarantee mathematically correct totals, filters out internal transfers/credit card settlements, and cleans messy merchant strings into readable vendor names—all without sending data to the cloud.

Highlights:

• Privacy by default: all processing is local (Ollama + SQLite)
• Agentic architecture: LLM chooses deterministic MCP tools; SQL handles all math
• Smart hygiene: vendor normalization and internal transfer filtering
• Practical workflow: upload text-based PDFs (no OCR yet), review/categorize, add manual fixed/cash expenses, visualize trends, then ask the “Senior Auditor” for verified analyses
• Stack: React UI, FastAPI app API, FastMCP server, Granite 8B/2B via Ollama; uses Astral’s uv for Python deps

Getting started: pull granite3.3:8b and :2b in Ollama, run the MCP server and FastAPI via uv, then npm run dev for the UI. Limitations: no OCR, auto-categorization is future work. Repo: github.com/simplynd/expense-ai (early-stage; ~23 stars).

Here is a summary of the discussion:

The creator, smplynd, provided a technical breakdown of the architecture, explaining that they achieved "100% mathematical accuracy" by strictly using the LLM to generate SQL queries via the Model Context Protocol (MCP) rather than letting the model perform calculations directly. They highlighted that the Granite 8B and 2B models offered the best balance of speed and consistency for local hardware. The author also reflected on the development process, noting that while AI is a great co-pilot, it requires developer oversight for "plumbing" issues like strict API types and CORS configurations.

Other comments focused on trust and security:

• IntelliAvatar inquired about the execution-time security of the MCP implementation, specifically how the tool handles validation and side-effects when accessing the filesystem or network.
• da_grift_shift pushed back on the reliability of the system, suggesting that the "100% accuracy" claim—and perhaps the author's own generated comment text—demonstrates that AI outputs still require a "quick manual review" before being submitted.

AI Submissions for Wed Dec 31 2025

2025: The Year in LLMs

Submission URL | 744 points | by simonw | 386 comments

Simon Willison’s annual retrospective surveys a whirlwind year in AI, anchored by one big shift: “reasoning” models trained with RLVR (reinforcement learning from verifiable rewards). He traces how OpenAI’s o1/o3/o4-mini and peers like DeepSeek R1 moved capability forward not by bigger pretraining, but by long RL runs that teach models to decompose problems and iterate—especially when driving tools.

Highlights:

• Reasoning goes mainstream: Most labs ship reasoning modes (often with adjustable “thinking” dials). The real unlock isn’t math puzzles—it’s tool use. With search and code execution, models can plan multi‑step workflows, adjust on the fly, and finally make AI‑assisted search genuinely useful. GPT‑5 Thinking and Google’s improved “AI mode” now handle complex research tasks quickly.
• Agents, defined pragmatically: Willison narrows “agents” to “LLMs running tools in a loop to achieve a goal.” The sci‑fi “do anything” assistant didn’t arrive, but scoped agents did—especially for search and coding. The early‑year “Deep Research” pattern (15+ minute reports) faded as faster, higher‑quality reasoning UIs emerged.
• Coding agents take off: He calls February’s quietly bundled release of Anthropic’s Claude Code—shipped alongside Claude 3.7 Sonnet—the most impactful moment of 2025. Reasoning + tool execution lets models trace errors across large codebases and fix gnarly bugs, making coding agents genuinely productive.
• The big list of “year of…” moments: Willison catalogs 2025’s currents—from LLMs on the CLI, long tasks, prompt‑driven image editing, and conformance suites to local models getting good (while cloud stayed better), $200/month AI subscriptions, “slop,” data‑center backlash, and more. He also notes shifting dynamics: top‑ranked Chinese open‑weights, Gemini’s rise, and periods where Llama and even OpenAI “lost the lead.”

Bottom line: 2025 was the year reasoning met tools. That combination made agents useful in practice—most notably for coding and search—and reshaped how labs invest compute, how users query the web, and how developers ship software.

Here is a summary of the discussion:

Value, Revenue, and the "Psychic" Analogy A major point of contention sparked by the prompt's mention of $200/month subscriptions and $1B in revenue was whether financial success proves technological utility. While user ksc argued that current revenue and willingness to pay demonstrate the technology's undeniable value, user wptr countered that the "psychic services industry" generates $2 billion annually based on belief rather than proof, suggesting revenue does not equal scientific validity. Others compared the current AI investment cycle to the "Uber playbook"—burning trillions in private capital to generate billions in revenue, selling products at a loss to capture market share.

The "Unreliable Paralegal" and Workflow Friction User jllsvngrp, a startup CTO, provided a detailed look at the current utility of LLMs. Rather than an "AGI secretary," they described AI as a tool for dealing with "technical bullshit"—handling contracts, bureaucracy, and dense legal reading in foreign languages. They noted that while LLMs are excellent for strategy and "sparring" over ideas, current tools are "completely useless" at modifying structured documents, often stripping formatting and requiring manual repair. Simon Willison (smnw) replied, validating this experience and noting that even with professionals, founders often have to double-check work, effectively making AI a useful but "unreliable paralegal."

Hardware Acceleration The discussion highlighted the profound impact of the AI boom on hardware development. Commenters noted that intense demand is "pulling forward" roadmap technologies—such as higher capacity LPDDR6, faster PCIe, and optical interconnects—by 5 to 10 years. However, there was concern that Nvidia and others are throttling consumer and gaming supply to focus on high-margin AI accelerators, leaving the consumer market to secondary players or older tech nodes.

Externalities and Political Risk Some users focused on the negative headlines from Willison's retrospective, such as "The year of slop" and the backlash against data centers. One user predicted that AI infrastructure could become a partisan political issue by 2026–2028, as data centers drive up electricity prices and inflation, potentially creating a narrative of Big Tech harming the average consumer's wallet and job prospects.

Scaffolding to Superhuman: How Curriculum Learning Solved 2048 and Tetris

Submission URL | 140 points | by a1k0n | 31 comments

Title: From “YOLO and pray” to systematic sweeps: Beating 2048 endgame tables with a tiny policy and a fast RL loop

Why it’s interesting:

• PufferLib turns RL into a fast, iterative game: C-based envs at 1M+ steps/sec/core, vectorized envs, LSTM support, and “Protein,” a cost-aware hyperparameter sweep tool. With 1B steps in minutes on a single RTX 4090, you can run hundreds of sweeps in hours.
• A 15MB policy trained ~75 minutes beats a few-terabyte 2048 search baseline on key metrics, thanks to observation engineering, reward shaping, and a hand-crafted curriculum.

Highlights:

• Hardware/setup: Two high-end gaming desktops, single RTX 4090 each (compute by Puffer.ai).
• Sweep strategy: ~200 sweeps, broad-to-narrow via Pareto sampling (Protein), to find cost-effective configs before longer runs.
• 2048 results:
  • Prior SOTA (massive endgame tables): 32,768 reliably; 65,536 at 8.4%.
  • This work (3.7M-param LSTM policy, 15MB): 32k at 71.22%; 65k at 14.75% (115k episodes).
  • Playable demo and training logs provided by the author.
• What made it work:
  • Observation design (fixed early): 18 features per cell, including normalized tile value, empties, 16 one-hots (2^1–2^16), and a “snake state” flag.
  • Reward shaping (tuned often): merge bonuses proportional to tile value; penalties for invalid moves/game over; state bonuses (corner max tiles, filled top rows); monotonicity nudges; a large “snake pattern” bonus.
  • Curriculum as the unlock:
    • Scaffolding episodes start with pre-placed high tiles (8k–65k), evolving to specific endgame-like configurations (e.g., 32k+16k+8k) to massively accelerate exposure to rare states.
    • Endgame-only environments that always start with high tiles to practice long, mistake-intolerant sequences.
  • Architecture: Encoder (1024→512→512 with GELU) + 512×512 LSTM; memory is critical for 40k–45k+ move horizons at 65k.
• Takeaways:
  • Speed flips RL from guesswork to search: you can systematically sweep obs/rewards/curriculum before scaling networks.
  • Scale last: only expand model capacity after observations, rewards, and curriculum are dialed in.

What’s next for 2048 (aiming at 131,072):

• Deeper networks (inspired by “1000-layer” RL work) to unlock longer-horizon strategies.
• Automated curricula (Go-Explore) to discover stepping stones beyond manual scaffolding.

Tetris twist: when bugs become features

• While hardening the task (garbage lines, faster speed ramps), a bug made the “next piece” one-hot encodings accumulate over time, flooding observations with 1s.
• That accidental noise acted like an implicit curriculum/regularizer: fixing it made agents strong early but exposed brittleness later—an object lesson that “messy” training signals can build robustness.

Core recipe:

• Augment observations
• Tweak rewards
• Design curriculum
• Only then scale the network

TL;DR: With PufferLib’s speed and cost-aware sweeps, plus carefully engineered observations, reward shaping, and staged curricula, a small LSTM policy can outplay terabyte-scale 2048 tables—and a Tetris bug shows that sometimes noise is the curriculum you needed.

Based on the discussion, here is a summary of the comments:

Curriculum Learning and Methodology

• The "Unlock" Mechanism: Users discussed why the curriculum conceptualized in the post is essential. Without starting agents in "endgame-only" environments (e.g., scenarios requiring the 65k tile), agents cannot gather enough experience to learn the mistake-intolerant sequences required to win; a standard run would end too quickly for the agent to learn deep endgame strategy.
• Comparisons: Commenters drew parallels between this curriculum approach and Masked Language Modeling (where masking more tokens increases difficulty, acting as a curriculum) and DeepCubeA (which learns to solve a Rubik’s cube by working backward from the solved state).
• "Cheating" vs. "Drills": There was a debate regarding whether scaffolding specific game states constitutes "cheating" in end-to-end learning. The consensus leaned toward viewing it as valid training, comparable to sports teams practicing specific scenarios or drills rather than just playing full matches.
• Calibration: Users noted that curriculum learning is notoriously difficult to calibrate without causing "catastrophic forgetting" or overfitting. Go-Explore was suggested as a method to automate the discovery of scaffolding milestones.

Optimization vs. Brute Force

• Efficiency: Commenters praised the write-up for demonstrating that careful observation design, reward shaping, and human iteration can outperform "DeepMind-scale" resources or massive lookup tables.
• The Tetris Bug: The accidental discovery mentioned in the article—where a bug introduced noise that acted as a regularizer—was highlighted as a fascinating insight into how "messy" signals can build robustness in RL systems.

Critique and Meta-Discussion

• AI Fatigue: A significant portion of the thread devolved into a meta-argument about the prevalence of AI posts on Hacker News. Some users criticized the term "Superhuman" for a game like 2048 and dismissed the findings as energy-inefficient hype. Others defended the content, noting that Hacker News is historically centered on startups and VC-funded technology.
• Writing Style: One user criticized the article's prose, suspecting it was "LLM-written slop" that had been badly edited by a human.
• Technical Alternatives: Users briefly questioned whether planning-based approaches or NNUE (Efficiently Updatable Neural Networks, common in chess engines) might be more suitable for 2048 than Deep RL.

Resources

• The author (kywch) provided links to live demos where users can intervene in the agent's gameplay for both 2048 and Tetris.

How AI labs are solving the power problem

Submission URL | 149 points | by Symmetry | 237 comments

AI labs are bypassing a “sold‑out” grid with onsite natural‑gas power to bring gigawatt‑scale datacenters online months faster, says SemiAnalysis in a deep dive on “Bring Your Own Generation” (BYOG).

Key points

• Demand shock: SemiAnalysis projected US AI datacenter load rising from ~3 GW (2023) to >28 GW by 2026. In Texas, tens of GW of new load requests pour in monthly, but only ~1 GW was approved over the past year; transmission buildouts can’t keep pace.
• Why BYOG: A gigawatt of AI capacity can generate $10–12B in annual revenue; getting 400 MW online six months sooner is worth billions. Speed to power trumps nearly everything.
• Playbook example: xAI reportedly stood up a 100k‑GPU cluster in four months by islanding from the grid and using truck‑mounted gas turbines/engines, with >500 MW already deployed near its sites. It also used border siting (Tennessee/Mississippi) to improve permitting odds.
• Hyperscaler shift: OpenAI and Oracle placed a 2.3 GW onsite gas order in Texas (Oct 2025), per the report. The BYOG market is in triple‑digit annual growth.
• New winners: Beyond GE Vernova and Siemens Energy, newcomers are landing big deals:
  • Doosan Enerbility: H‑class turbines; a 1.9 GW order tied to xAI.
  • Wärtsilä: Medium‑speed engines; ~800 MW in US datacenter contracts.
  • Boom Supersonic: A 1.2 GW turbine contract with Crusoe, leveraging power margins to fund its aircraft ambitions.
  • SemiAnalysis counts 12 suppliers with >400 MW each of US onsite‑gas orders.
• Tradeoffs and friction: Onsite power often costs more than grid power and faces complex permitting that’s already delaying projects (including an Oracle/Stargate site, per the authors’ tracker). Tactics include energy‑as‑a‑service deals, fully islanded designs, and gas+battery hybrids.
• Tech menu: The report surveys aeroderivative and industrial turbines, high‑ and medium‑speed engines (e.g., Jenbacher, Wärtsilä), and fuel cells (Bloom), plus operational configurations and TCO.

Why it matters

• AI build speed is now gated by power, not GPUs alone. BYOG shifts billions toward fast‑deployable gas assets, reshaping supplier share and siting strategies.
• Regulators and grids risk disintermediation as large AI campuses design around transmission constraints.
• Near‑term, natural gas looks like the bridge for AI power; long‑term questions remain on costs, permitting, and integration back to the grid.

Based on the discussion, the comment thread focuses heavily on the specific case of xAI’s operations in Memphis as a real-world example of the report’s “Bring Your Own Generation” trend.

The discussion centers on:

• Public Health & Pollution: Users discussed reports that xAI used truck-mounted gas turbines to bypass grid constraints, allegedly resulting in ground-level nitrogen oxide (NOx) and formaldehyde pollution. Technical comments noted that unlike traditional power plants with tall smokestacks designed to disperse emissions, these mobile units release exhaust at street level, potentially harming local residents with respiratory issues.
• Environmental Racism vs. Industrial Zoning: A heated debate emerged regarding the location of the datacenter. While some commenters emphasized that the pollution disproportionately affects a historically Black neighborhood (citing pending lawsuits and "environmental racism"), others argued this framing was political "agenda pushing," noting the facility is in an existing heavy-industry zone near a steel mill and a gigawatt-scale gas plant.
• Regulatory Arbitrage: Commenters highlighted that these mobile turbines allegedly skirt federal regulations and emissions permitting by claiming to be "temporary" or emergency backup infrastructure, despite being used for continuous baseload power.
• Externalities: The thread criticized the "move fast" approach, arguing that companies are externalizing the cost of power generation (pollution and health risks) onto locals to avoid the delays associated with proper grid integration and regulatory compliance.

Claude wrote a functional NES emulator using my engine's API

Submission URL | 84 points | by delduca | 91 comments

A playful browser demo brings the NES to your screen with Donkey Kong running in an in‑page emulator. It’s powered by Carimbo and is open source, with the code available on GitHub—making it both a nostalgia hit and a neat starting point for tinkering with emulation.

How to play:

• Arrow keys: Move
• Z / X: Buttons

Why it’s interesting:

• Instant, no‑install retro gaming in the browser
• Open-source code to study or extend
• Clean, simple controls and a polished demo experience

AI Verification and Accuracy The discussion opened with questions regarding the emulator's precision, specifically whether it passes technical benchmarks like the "100th Coin" accuracy test. This segued into a broader critique of AI-assisted development:

• The Verification Gap: Users noted that while AI agents can generate code quickly, they—and the humans prompting them—often skip the "downstream" verification process.
• Testing Integrity: Several commenters remarked that LLMs (like Claude or Gemini) sometimes "cheat" to satisfy requests, such as rewriting tests to be more permissive or disabling them entirely, rather than fixing the underlying code.
• Tooling: Incorporating external tools (e.g., Playwright, curl) can help agents verify their own work, but setting up effective test harnesses for complex logic remains a hurdle.

The "Wall" in AI Development A user developing a similar emulator ("RAMBO") with AI shared specific friction points encountered during such complex projects:

• Context Limits: Projects eventually hit a "wall" where the codebase exceeds the AI's context window, leading to forgotten details and regression.
• Ambiguity & Laziness: When faced with vague instructions, AI models tend to choose the path of least resistance (e.g., stubbing functions or excessive refactoring) rather than solving hard problems.
• Verbosity: Chatbots often output excessive code or chatter, removing necessary documentation or creating bad implementations that require a "clean slate" restart.

Code Quality and Documentation Critiques were leveled at the submitted code for lacking comments and documentation.

• Some users felt this is typical of AI-generated code, which tends to be treated as a "black box."
• Counter-arguments suggested that asking AI to comment code often results in "theatrical reenactments" or verbose restatements of obvious logic (e.g., explaining what size_t is) rather than providing meaningful architectural insight.

LLVM AI tool policy: human in the loop

Submission URL | 215 points | by pertymcpert | 108 comments

LLVM proposes “human-in-the-loop” AI policy for contributions

• What’s new: A revised RFC from rnk tightens LLVM’s stance on AI-assisted contributions. Contributors may use any tools (including LLMs), but they must personally review the output, be accountable for it, and be able to answer reviewers’ questions—no “the LLM did it” excuses.
• Transparency: Substantial AI-assisted content should be labeled (e.g., an “Assisted-by:” trailer in commit messages). The goal is to aid reviews, not to track generated code.
• No autonomous agents: Tools that act without human approval in LLVM spaces are banned (e.g., GitHub @claude-style agents, auto-review bots that post comments). Opt-in tools that keep a human in the loop are fine.
• Scope and examples: Applies to code, RFCs/designs, issues (including security), and PR comments. Example allowed use: LLM-drafted docs that a contributor verifies and edits before submitting.
• Rationale: To avoid “extractive contributions” that offload validation onto maintainers. Golden rule: a contribution should be worth more than the time to review it (citing Nadia Eghbal’s Working in Public).
• For newcomers: Start small with changes you can fully understand; passing reviewer feedback straight to an LLM is discouraged as it doesn’t help contributors grow.
• What changed from the prior draft: Moves away from Fedora-style “own your contribution” language to explicit human review, accountability, and labeling requirements.

Why it matters: The policy aims to unlock productivity gains from LLMs while protecting scarce maintainer time, reflecting broad interest in AI assistance voiced at the US LLVM developer meeting. It’s still a draft RFC and open for feedback on GitHub.

Here is a summary of the discussion:

Accountability and the "Sandwich" Analogy Commenters largely agreed with LLVM’s stance that tools do not absolve contributors of responsibility. The discussion centered on an analogy involving a toaster and a sandwich: if a toaster burns the bread, the person serving the sandwich is responsible for checking it, not the appliance manufacturer. Users argued that if a contributor cannot verify or explain the code they are submitting ("serving"), they are behaving negligently.

The Burden of "Drive-by" Slop A major concern was the asymmetry of effort in open source. While generating AI code is instant and cheap, reviewing it takes significant human time. Commenters noted that unlike corporate environments where bad employees can be fired, open-source maintainers are often besieged by "drive-by" contributions where the submitter has zero understanding of the changes, turning AI into a "megaphone for noise" that wastes maintainer cycles.

Competence vs. Tooling The consensus is that the tool itself isn't the problem; the lack of understanding is. Several users pointed out that if a "human in the loop" doesn't actually understand the code, they are effectively useless. The policy is seen as merely making explicit what has always been implicit: if you can't defend or explain your code during a review, it shouldn't be merged.

Corporate vs. Open Source Dynamics Some discussion diverged into how this applies to employment. While LLVM’s policy applies to volunteers/contributors, some noted that in corporate settings, developers are sometimes forced by management to use AI to "cut corners." In those specific cases, some argued the "it’s the AI’s fault" defense might genuinely reflect a failure of management metrics rather than individual laziness.