Hacker News
Daily AI Digest

AI Submissions for Tue Nov 11 2025

We ran over 600 image generations to compare AI image models

Submission URL | 190 points | by kalleboo | 99 comments

LateNiteSoft (makers of Camera+, Photon, REC) ran 600+ AI image edits to see which models work best for everyday photo tweaks—and to decide what to support in their new MorphAI app. Because they refuse “unlimited” AI pricing with fair‑use gotchas, they built CreditProxy, a pay‑per‑generation billing layer (and are inviting trial users).

How they tested

• Realistic use cases: pets, kids, landscapes, cars, product shots
• Naive prompts (what typical users actually type), not prompt‑engineered
• Tracked speed and behavior across models

Latency (avg during tests)

• OpenAI gpt-image-1: High ~80s (Medium ~36s)
• Gemini: ~11s
• Seedream: ~9s
• Times were stable across prompts

Findings

• Classic/photoreal filters: Gemini best preserves original detail and resists hallucinations, but often weakens or refuses edits—especially on people. OpenAI applies stronger looks but introduces “AI slop,” notably on faces. Seedream had some odd shortcuts.
• Long exposure: OpenAI did best when the effect made sense (landscapes, cars) but failed on cats/product and got trippy on portraits. Gemini often did nothing. Seedream leaned on generic light streaks.
• Heat map: None showed real “heat” understanding; Seedream mostly assumed humans emit heat.
• Creative effects (vintage, kaleidoscope, etc.): Gemini is conservative; OpenAI more creative but less faithful.

Why it matters

• Model choice should be task‑driven: Gemini for faithful edits, OpenAI for bold stylization (with risk), Seedream for speed and low cost but less grounding.
• For consumer photo apps, predictable costs, latency, and “do no harm” edits often beat raw creativity.

There’s a big, flip‑throughable comparison gallery on the post (with keyboard shortcuts).

Summary of Hacker News Discussion:

1. Model Comparisons & Quirks:

   • Gemini is praised for preserving details and refusing risky edits (e.g., faces), but often returns unchanged images or weakens edits.
   • OpenAI (GPT-image-1) is seen as more creative but introduces "AI slop," altering faces/objects and applying a yellow tint. Users debate whether this tint is intentional (e.g., vintage styling) or a technical flaw.
   • Seedream excels in speed and cost but sacrifices detail, using shortcuts like generic light streaks.

2. Technical Insights:

   • OpenAI’s pipeline regenerates images semantically rather than editing pixels directly, leading to unintended changes (e.g., altered faces). This is attributed to tokenization and latent space architecture.
   • Gemini’s conservatism, especially with people, may stem from safety filters.

3. Practical Challenges:

   • Users report frustration with models ignoring prompts (e.g., Gemini refusing edits) or altering unintended areas, necessitating manual checks.
   • Cost and latency matter: Seedream’s speed appeals to small creators, while OpenAI’s pricing and reliability raise concerns.

4. Community Reactions:

   • Skepticism about "AI slop" as hype vs. substance, with critiques of stock photo industry impacts.
   • Debate over whether OpenAI’s yellow tint is a feature (stylistic choice) or a bug.
   • Interest in hybrid workflows (e.g., SDXL, LoRAs) for better control, highlighting a gap in commercial SaaS offerings.

5. Notable Quotes:

   • "Models sometimes alter objects they weren’t supposed to touch… a complete failure."
   • "Peak quality in realistic rendering might already be behind us." (referring to DALL-E 3’s trade-offs).

Key Takeaway:
The discussion underscores the need for task-specific model selection, transparency in AI editing behavior, and tools that balance creativity with fidelity. Community sentiment leans toward cautious adoption, emphasizing manual oversight and hybrid approaches for professional use.

Scaling HNSWs

Submission URL | 206 points | by cyndunlop | 42 comments

Scaling HNSWs: antirez’s hard-won lessons from bringing HNSW to Redis

• Not just another intro: After a year building an HNSW-based “Redis experience,” antirez shares advanced, practical insights—what it takes to make HNSW low-latency and production-ready, not just paper-correct.
• HNSW isn’t the final form: The original paper is excellent but incomplete for real systems. He added true deletions (beyond tombstones), and questions how necessary the hierarchy (“H”) really is—early results suggest a flat, single-layer variant can work but with higher seek time. The sweet spot may be modified level selection rather than all-or-nothing.
• Memory is the real enemy: HNSW is pointer-heavy and multi-level; vectors are big. Extra layers cost ~1.3x space on average (with p=0.25), so hierarchy isn’t the main bloat—vector storage is.
• Biggest win: 8‑bit quantization by default. Per-vector max-abs scaling delivers roughly 4x faster search and ~4x smaller vectors with near-identical recall in practice. Pointers still dominate some footprint, but this is the low-hanging fruit that moves the needle in Redis.
• Why this quantization: Using a single max-abs per vector keeps cosine similarity fast—compute a simple scale factor and do the heavy lifting in the integer domain with unrolled loops and multiple accumulators for modern CPUs. It’s faster than min/max quantization while preserving accuracy.
• Tradeoffs he didn’t take (yet): Pointer compression could save memory (upper bytes often identical on 64-bit) but may cost latency; he hasn’t adopted it given Redis’s performance bar.
• Direction of travel: Don’t assume “evolution” just means on-disk HNSW. There’s room for fresh data-structure ideas around hierarchy, level selection, deletions, and quantization that can beat conventional wisdom.

Why it matters: If you’re building vector search in latency-sensitive systems, quantization and careful algorithmic choices can deliver big wins without killing recall—and some revered parts of HNSW may be optional with the right tweaks. Redis Vector Sets ships with 8-bit quantization on by default for exactly these reasons.

Summary of Discussion:

The discussion around antirez's insights on scaling HNSW for Redis highlights several technical challenges, trade-offs, and alternative approaches in vector search systems:

1. Filtered Searches & Performance

• Applying metadata filters (e.g., regional constraints) during HNSW traversal can degrade performance, as it requires checking each candidate vector against filter criteria. Solutions like Turbopuffer (200ms latency for 100B vectors) and Vespa’s hybrid search were cited as addressing this, though antirez notes Redis prioritizes low-latency by limiting graph traversal depth early if filters are restrictive.
• Lucene/Elasticsearch shortcuts filtering by pre-determining eligible nodes, but worst-case scenarios still involve brute-force distance comparisons.

2. Quantization & Efficiency

• Redis’s 8-bit per-vector quantization (using max-abs scaling) was praised for reducing memory usage by ~4x and speeding up searches while preserving recall. Critics noted that DiskANN and other systems achieve similar gains via int8/binary quantization but require trade-offs in recall.
• antirez clarified that Redis’s approach prioritizes CPU-friendly integer operations and avoids complex schemes like product quantization (PQ), balancing practicality with near-identical recall for most use cases.

3. Hierarchy in HNSW

• Debate arose over whether HNSW’s hierarchical layers ("H") are essential. antirez’s experiments suggest a flat, single-layer variant could suffice with higher seek times, proposing modified level selection as a middle ground. Academic references (e.g., "Hubs in HNSW") were shared, underscoring ongoing research into hierarchical efficiency.

4. Implementation Challenges

• Memory vs. Latency: Pointer compression was discussed but deemed risky for Redis’s strict latency goals.
• Single-Threaded Design: Redis’s single-threaded model influenced HNSW implementation choices, favoring simplicity and deterministic performance over parallelism.

5. Alternative Approaches

• Vespa and SPFresh were highlighted for hybrid search optimizations.
• Broader themes emerged on system design philosophy: Simplicity and "good enough" solutions (e.g., 60th vs. 72nd recall percentile) often trump theoretical perfection, especially in latency-sensitive applications like RAG.

Key Takeaway:

The discussion underscores that real-world vector search systems require pragmatic trade-offs—quantization, filtered search shortcuts, and hierarchy adjustments—to balance speed, memory, and recall. Redis’s choices reflect a focus on practical, low-latency solutions over algorithmic purity.

Adk-go: code-first Go toolkit for building, evaluating, and deploying AI agents

Submission URL | 80 points | by maxloh | 23 comments

Google open-sources ADK for Go: a code-first toolkit for building and deploying AI agents

What it is: ADK (Agent Development Kit) for Go is a modular, model-agnostic framework focused on building, evaluating, and orchestrating AI agents using idiomatic Go. It’s optimized for Gemini but works with other models and frameworks.

Why it matters: Go is a natural fit for cloud-native, concurrent systems. ADK brings a strongly typed, testable, versionable approach to agent development—aimed at production-grade workloads and multi-agent orchestration—without locking you into a specific model or deployment target.

Highlights

• Code-first and idiomatic Go: define agent logic, tools, and orchestration in code for flexibility and testability.
• Rich tool ecosystem: use prebuilt tools or wire in custom functions to extend agent capabilities.
• Multi-agent systems: compose specialized agents into larger workflows.
• Deploy anywhere: easy containerization; strong fit for Cloud Run and cloud-native environments.
• Model-agnostic, Gemini-optimized: integrates with Gemini while staying portable.

Quick start: go get google.golang.org/adk

Details: Apache-2.0 licensed, ~2.8k GitHub stars, with companion ADKs for Python and Java plus docs and samples at google.github.io/adk-docs/.

Summary of Hacker News Discussion:

Key Themes

1. Go’s Strengths for AI Agents:

   • Concurrency & Performance: Users highlight Go’s native concurrency (goroutines/channels) as ideal for AI agents handling parallel tasks (e.g., HTTP requests, database operations) without serialization bottlenecks. Its compiled binaries and efficiency suit cloud/serverless deployments (e.g., Cloud Run).
   • Type Safety & Testability: Go’s strong typing and idiomatic design enable reliable, maintainable agent code. Some contrast this with Python’s flexibility, which can lead to runtime errors in complex systems.

2. Comparison with Python/Java:

   • Python ADK: Praised for simplicity (e.g., defining agents as objects with tools) and built-in features (debugging, session management). However, Go is seen as better for production-scale systems requiring strict concurrency and type safety.
   • Java: Noted for enterprise-grade performance but seen as less agile for rapid agent development. Go strikes a balance between performance and developer ergonomics.

3. Use Cases & Skepticism:

   • Production Readiness: Users see ADK-Go as promising for multi-agent orchestration in cloud-native environments, especially with Gemini optimizations. Some question if inference latency (often model-dependent) negates Go’s runtime advantages.
   • Model Agnosticism: While Gemini-optimized, the framework’s portability across models (e.g., OpenAI, Claude) is appreciated, though integration efforts vary.

4. Tooling & Ecosystem:

   • Prebuilt Tools: The ADK’s tool ecosystem (e.g., HTTP/SQLite connectors) simplifies agent development. Custom tool integration via Go functions is seen as a plus.
   • Debugging/Orchestration: Features like session management and callbacks for data anonymization are highlighted as valuable for complex workflows.

Notable Opinions

• Rust vs. Go: A user notes Rust’s popularity but argues Go’s concurrency model is more approachable for agent development.
• Python’s Dominance: Some acknowledge Python’s hold on AI prototyping but see Go as better for scaling “script-like” agents into robust applications.
• Deployment Flexibility: Go’s compiled binaries are praised for serverless/edge deployments, with one user sharing success in production serverless functions.

Criticisms & Questions

• Learning Curve: A few users express surprise at Go’s type-driven agent definitions (similar to TypeScript) but find it manageable.
• Gemini Lock-In?: Clarified that ADK is model-agnostic, though Gemini optimizations are a focus.

Miscellaneous

• Community Excitement: Several users express enthusiasm for Go’s role in advancing multi-agent systems and cloud-native AI.
• References: Links to prior HN posts about agents and Claude’s Python implementation are shared for comparison.

Overall Sentiment: Positive, with developers seeing ADK-Go as a compelling option for building scalable, type-safe AI agents in production, particularly where concurrency and cloud-native deployment matter. Python remains favored for prototyping, but Go’s strengths in reliability and performance are seen as filling a critical niche.

Xortran - A PDP-11 Neural Network With Backpropagation in Fortran IV

Submission URL | 46 points | by rahen | 10 comments

XOR Neural Network in FORTRAN IV (RT-11, PDP-11/34A) — A delightful retrocomputing crossover: a tiny multilayer perceptron that learns XOR, written in 1970s-era FORTRAN IV and run under RT-11 on a PDP‑11/34A (via the SIMH emulator). It’s a legit backprop network: 1 hidden layer (4 neurons, leaky ReLU), MSE loss, tanh output, “He-like” Gaussian init via a Box–Muller variant, and learning-rate annealing. The whole thing trains 17 parameters and converges in minutes on real hardware (or at a realistic 500K throttle in SIMH), printing loss every 100 epochs and nailing the XOR targets. It compiles with the original DEC FORTRAN IV compiler and needs just 32 KB plus an FP11 floating-point unit. Includes an RT‑11 disk image, so you can attach it in SIMH and run, or build with .FORTRAN and .LINK. A neat proof that backprop doesn’t require modern frameworks—just patience, floating point, and a 1970s minicomputer.

The discussion highlights a mix of nostalgia, technical insights, and historical context around retrocomputing and early neural networks:

• Retro Hardware & Neural Networks: Users reminisce about professors implementing neural networks on PDP-11s in the 1980s, noting limitations like the PDP-11/34A’s modest power (roughly comparable to an IBM XT) but praising its ability to handle sustained workloads with its FPU. References are made to historical models like the Neocognitron (1980s) and the role of VAX systems in later backpropagation research.

• FORTRAN IV Nuances: Debate arises around FORTRAN IV’s features, including its use of FORTRAN 66 extensions, lack of modern constructs (e.g., structured If/Then/Else), and reliance on hardware FPUs or software emulation. The project’s compatibility with the original DEC compiler and constraints (32 KB memory, FP11 support) sparks appreciation for its efficiency.

• Humor & Corrections: A lighthearted thread corrects Fortran version timelines (Fortran IV in 1966 vs. Fortran 77 in 1977), jokingly referencing Charles Babbage’s Analytical Engine. Another user points out the ironic overlap between PDP-11 hardware and the “Parallel Distributed Processing” (PDP) connection in neural network literature.

• Appreciation for Simplicity: Commentators laud the project for demonstrating core concepts without modern frameworks, emphasizing the value of understanding fundamentals over today’s complexity.

Overall, the exchange blends technical admiration for early computing with wry humor about its historical quirks.

AI documentation you can talk to, for every repo

Submission URL | 161 points | by jicea | 118 comments

Devin DeepWiki: turn any repo into an AI‑generated code wiki A new tool called Devin DeepWiki promises “index your code with Devin,” letting you add a GitHub repo and get a browsable, wiki‑style view of the codebase with AI summaries and search. The demo shows a catalog of popular projects (VS Code, Transformers, Express, SQLite, React, Kubernetes, etc.) you can pick to “understand,” suggesting it pre‑indexes large OSS repos for instant exploration. The pitch is faster onboarding and code comprehension: instead of hopping across files, you get cross‑linked context and natural‑language explanations.

Why it’s interesting

• Speaks to the growing demand for AI‑first code navigation and docs, competing with tools like Sourcegraph/Cody, CodeSee, and auto‑docs generators.
• Could be useful for due diligence, learning popular frameworks, or ramping onto large legacy codebases.

What to watch

• Accuracy and hallucinations in summaries; keeping the wiki in sync with fast‑moving repos.
• Privacy/security for private code and indexing scope.
• How it handles truly large monorepos and language/tooling diversity.

The discussion around Devin DeepWiki highlights skepticism and critical feedback, focusing on accuracy, documentation integrity, and practical usability:

1. Accuracy Concerns:

   • Users criticize AI-generated summaries and diagrams for being outdated, incorrect, or misleading. For example, the tool inaccurately claims a VS Code extension exists, but the linked repository shows it’s experimental/unreleased.
   • Debate arises over whether AI can reliably handle subjective or nuanced topics (e.g., React vs. functional frameworks, OOP vs. FP), with concerns that LLMs might reinforce biases or misinterpretations instead of clarifying them.

2. Documentation Frustrations:

   • The project’s own documentation is flagged as confusing or incomplete, such as installation instructions for an unreleased VS Code extension. Users note that incomplete or incorrect docs waste time and erode trust, especially for contributors trying to build/use the tool.
   • A meta-point emerges: If AI-generated docs (like DeepWiki’s) are error-prone, they risk creating a “hallucination spiral” where future AI models train on flawed data, worsening accuracy over time.

3. Project Transparency:

   • Critics argue the demo’s pre-indexed OSS repos (e.g., VS Code, React) mask the tool’s limitations. The maintainer admits parts are experimental but defends the approach as a calculated risk.
   • Some users question the ethics of promoting unfinished tools, suggesting it prioritizes hype over practicality, especially for private codebases.

4. Mixed Reactions to AI’s Role:

   • While some acknowledge AI’s potential to surface high-level insights, others stress that human-curated documentation remains irreplaceable for precision.
   • A recurring theme: AI-generated docs might complement but not replace manual efforts, particularly in filling gaps for legacy/unmaintained projects.

Key Takeaway:
The discussion reflects cautious interest in AI-powered code navigation tools but emphasizes the need for accuracy, transparency, and human oversight. DeepWiki’s current implementation raises red flags, but its concept sparks debate about balancing automation with reliability in developer tools.

How to Train an LLM: Part 1

Submission URL | 15 points | by parthsareen | 3 comments

What it is

• A hands-on series documenting the author’s attempt to build a domain-specific LLM from scratch. Part 1 sets a clean, “boring” Llama 3–style baseline and maps out the training math, memory, and token budgeting before getting fancy.

Model and data

• Architecture: ~1.24B params, Llama 3–ish
  • 16 layers, hidden size 2048, SwiGLU (×4), 32 heads with 8 KV heads (GQA), RoPE theta 500k, vocab 2^17, tied embeddings, no attention/MLP bias, norm_eps 1e-5.
• Context: targeting 4096 at the end, but trains mostly at 2048 (common practice: short context for 80–90% of steps, extend near the end).
• Data: Karpathy’s fine-web-edu-shuffled.
• No cross-document masking (for now).

Compute plan

• Hardware: 8×H100 80GB.
• Token budget: Chinchilla-style 1:20 params:tokens → ~20B tokens for a 1B model.
• Global batch target: 1M tokens (GPT-3 XL–style).
  • With FP32 ballpark estimates and a 5GB “misc” reserve per GPU, each H100 fits ~7×[2048] sequences per step.
  • Across 8 GPUs: micro-batch ≈ [56, 2048] = 114,688 tokens/step.
  • Gradient accumulation: ceil(1,048,576 / 114,688) = 10 micro-steps per global batch.
  • Steps: 20B / 1M = 20,000 optimizer updates; with accumulation, ≈200,000 forward/backward micro-steps.

Memory insights (intuition, FP32, unfused)

• Rough peaks by phase:
  • Forward: Weights + Activations.
  • Backward: Weights + Activations + Gradients (often the peak).
  • Optimizer step: Weights + Gradients + Optimizer states (~4× params in bytes).
• Activation memory dominates at realistic batch sizes due to unfused ops saving intermediates.
• Empirical activation cost scales linearly with batch size; ~7.95GB per [1,2048] sequence in this setup.

Immediate optimizations planned

• torch.compile and FlashAttention to fuse ops and slash activations.
• Gradient accumulation (already used).
• More to come (mixed precision, custom kernels, infra upgrades).

Why it matters

• Clear, number-first walkthrough of how far 8×H100 can push a 1B Llama-style pretrain without exotic tricks.
• Sets a reproducible baseline before exploring “BLASphemous” optimizations, longer context, inference-friendly tweaks, and a custom “token farm.”

What’s next

• Improving training infra, scaling token throughput, extending context efficiently, and architectural changes aligned with the final task. The domain target is still under wraps.

The discussion touches on contrasting perspectives about LLM deployment and hardware requirements:

1. Mobile vs. Server Debate: One user argues LLMs should prioritize optimization for mobile/portable devices (cheaper, easier maintenance) rather than expensive server infrastructure. They suggest deploying LLMs directly on phones or edge devices.

2. Counterexample with Laptops: A reply highlights running a 70B-parameter LLM on a $300 laptop with 96GB RAM using tools like llm.cpp, implying powerful models can already operate on consumer-grade hardware. The user mentions purchasing the laptop for non-AI reasons, suggesting incidental compatibility with AI workloads.

3. Unclear Contribution: A third comment ("cdcntnt nwbrrwd") appears fragmented or mistyped, offering no clear insight.

Key Takeaway: The exchange reflects ongoing tensions in the AI community between centralized (server-based) and decentralized (edge/mobile) LLM deployment strategies, with practical examples demonstrating feasibility on modest hardware.

AI Submissions for Mon Nov 10 2025

Using Generative AI in Content Production

Submission URL | 174 points | by CaRDiaK | 131 comments

What’s new: Netflix has issued detailed guidance for filmmakers, production partners, and vendors on when and how they can use generative AI in content production. Partners must disclose intended use; many low-risk, behind-the-scenes uses are fine, but anything touching final deliverables, talent likeness, personal data, or third-party IP needs written approval.

Key points

• Guiding principles:
  • Don’t replicate copyrighted or identifiable styles/works you don’t own.
  • Don’t let tools store, reuse, or train on production data; prefer enterprise-secured environments.
  • Treat GenAI outputs as temporary unless explicitly approved for final use.
  • Don’t replace or generate union-covered work or talent performances without consent.
• Always escalate/require written approval:
  • Data: No uploading unreleased Netflix assets or personal data without approval; no training/fine-tuning on others’ works without rights.
  • Creative: Don’t generate main characters, key visual elements, or settings without approval; avoid prompts referencing copyrighted works or public figures/deceased individuals.
  • Talent: No synthetic/digital replicas of real performers without explicit consent; be cautious with performance-altering edits (e.g., visual ADR).
• Custom AI pipelines by vendors are subject to the same rules; a use-case matrix is provided to assess risk.

Why it matters: This codifies a consent-first, enterprise-only stance that effectively blocks style mimicry and training on unowned data, keeps most AI output out of final cuts without approvals, and aligns with union and rights-holder expectations as studios formalize AI workflows.

Here's a concise summary of the key discussion points from the Hacker News thread about Netflix's GenAI rules:

Core Debate Topics

1. IP Protection & Creativity Balance

   • Strong support for Netflix’s "consent-first" stance protecting creators’ IP and union jobs.
   • Concern that overreliance on AI could lead to generic "slop" (dctrpnglss, xsprtd), undermining creative value.
   • Counterargument: Rules actually preserve creativity by reserving critical aspects (e.g., main characters, settings) for human artists (DebtDeflation).

2. Enforcement Challenges

   • Skepticism about how Netflix would detect AI-generated infringements (mls, bjt), especially subtle style mimicry.
   • Parallels drawn to gaming industry controversies (e.g., Call of Duty skins allegedly copying Borderlands, Arc Raiders AI voice acting contracts).

3. Copyright Precedents & AI Legal Risks

   • Links shared about Meta’s lawsuits over torrented training data (TheRoque).
   • Debate on whether AI output is inherently "infringement" or "slop" (SAI_Peregrinus, lckz), with some noting current U.S. law doesn’t recognize AI outputs as copyrightable.

4. Union & Talent Protections

   • Praise for strict rules on digital replicas/edits requiring performer consent (szd), seen as a direct win from the SAG-AFTRA strikes.
   • Relief that AI won’t replace union-covered roles without approval.

5. Corporate Strategy & Industry Impact

   • View that Netflix positions itself as a tech-platform first, making AI cost-cutting inevitable for background elements (smnw, yrwb).
   • Comparisons to Spotify’s algorithm-generated playlists reducing artist payouts.

Notable Subthreads

• Gaming Industry Tangent: Discussion diverged into Call of Duty’s perceived decline (p1necone, Der_Einzige) and Arc Raiders’ AI voice acting controversy (lckz).
• Philosophical Split: Is generative AI a tool enabling creativity (stg-tch) or inherently derivative "slop generation" (xsprtd)?
• Procedural Notes: Netflix’s requirement for "written approval" seen as a shield against liability (cptnkrtk, smnw).

Conclusion

While broadly endorsing the IP safeguards, the thread raised pragmatic concerns about enforcement difficulty and long-term creative degradation. Netflix’s move was framed as both a necessary legal shield and a potential harbinger of reduced human artistry in non-core content.

Omnilingual ASR: Advancing automatic speech recognition for 1600 languages

Submission URL | 147 points | by jean- | 40 comments

Meta unveils Omnilingual ASR: open-source speech recognition for 1,600+ languages

• What’s new: Meta’s FAIR team released Omnilingual ASR, a suite of models that transcribe speech in 1,600+ languages, including 500 low-resource languages reportedly never before transcribed by AI. They claim state-of-the-art results with character error rate under 10 for 78% of languages.
• How it works: A scaled wav2vec 2.0 speech encoder (up to 7B parameters) feeds two decoder options:
  • CTC decoder for classic ASR
  • “LLM-ASR” transformer decoder that brings LLM-style in-context learning to speech
• Bring-your-own-language: Users can add new or unsupported languages with only a handful of paired audio–text examples, no expert fine-tuning required. Zero-shot quality trails fully trained systems but enables rapid coverage growth.
• What’s released:
  • Omnilingual wav2vec 2.0 models and ASR decoders from lightweight ~300M to 7B
  • Omnilingual ASR Corpus: transcribed speech across 350 underserved languages
  • A language exploration demo
• Open source: Models under Apache 2.0, data under CC-BY, built on the fairseq2 PyTorch stack.
• Why it matters: This pushes beyond typical multilingual ASR to unprecedented language coverage, aiming to shrink the digital divide with community-driven extensibility and options spanning on-device to server-scale deployment.
• Caveats to watch: Metrics are reported in CER (not WER), zero-shot still lags trained systems, and the largest models will demand significant compute.

The Hacker News discussion about Meta's Omnilingual ASR highlights several key themes, critiques, and insights:

Key Points of Discussion

1. Language Classification Debates:

   • Users questioned the accuracy of language vulnerability ratings, citing oddities like Hungarian and Swedish being labeled "endangered" despite millions of speakers. Ethnologue data was referenced to correct misclassifications (e.g., Swedish is "Institutional," not endangered).
   • Humorous examples surfaced, such as Malayalam (35M speakers) mistakenly marked as "highly endangered."

2. Technical Performance & Comparisons:

   • The 300M parameter model was noted for practical on-device use, outperforming Whisper in some benchmarks. Users emphasized the importance of clean, diverse training data for low-resource languages.
   • Concerns were raised about transcription accuracy, particularly with word boundaries and timestamping, especially for tonal languages (e.g., Thai, African languages) and phoneme-rich systems.

3. Community-Driven Extensibility:

   • The "bring-your-own-language" feature was praised for enabling rapid adoption of underserved languages with minimal data. Users highlighted its potential for linguists and communities to preserve dialects.

4. Open-Source & Licensing:

   • While the Apache/CC-BY release was celebrated, some cautioned about derivative projects (e.g., Voice AI) potentially violating licenses. Others debated the balance between accessibility and commercialization.

5. Humorous Takes:

   • Jokes included applying ASR to animal communication (dolphins, bees) and调侃 the "Penguin language." One user quipped that supporting 1,600 languages felt like a "universal language" milestone.

6. Comparisons to Existing Tools:

   • Meta’s model was contrasted with Whisper, Mozilla’s TTS, and Google’s work on dolphin communication. Some noted Meta’s MMS TTS models lacked phoneme alignment steps, limiting usability.

Notable Critiques

• Metrics: Skepticism about CER (Character Error Rate) vs. WER (Word Error Rate), with CER ≤10% potentially masking higher word-level inaccuracies.
• Resource Requirements: Training even small models (300M params) demands significant GPU resources (~32 GPUs for 1 hour), raising concerns about accessibility.
• Language Coverage: While expansive, gaps remain (e.g., regional EU languages), and performance in truly low-resource settings needs validation.

Positive Highlights

• The release of the Omnilingual ASR Corpus and demo tools was seen as a leap toward democratizing speech tech.
• Users praised Meta’s focus on underrepresented languages, calling it a step closer to a "Babel Fish" for Earth.

Overall, the discussion reflects enthusiasm for Meta’s ambitious open-source push, tempered by technical skepticism and calls for clearer metrics and accessibility.

Benchmarking leading AI agents against Google reCAPTCHA v2

Submission URL | 117 points | by mdahardy | 87 comments

Benchmark: AI agents vs. Google reCAPTCHA v2. Using the Browser Use framework on Google’s demo page, the authors pitted Claude Sonnet 4.5, Gemini 2.5 Pro, and GPT-5 against image CAPTCHAs and saw big gaps in performance. Trial-level success rates: Claude 60%, Gemini 56%, GPT-5 28%. By challenge type (lower because a trial can chain multiple challenges): Static 3x3 was easiest (Claude 47.1%, Gemini 56.3%, GPT-5 22.7), Reload 3x3 tripped agents with dynamic image refreshes (21.2/13.3/2.1), and Cross-tile 4x4 was worst, exposing perceptual and boundary-detection weaknesses (0.0/1.9/1.1).

Key finding: more “thinking” hurt GPT-5. Its long, iterative reasoning traces led to slow, indecisive behavior—clicking and unclicking tiles, over-verifying, and timing out—while Claude and Gemini made quicker, more confident decisions. Cross-tile challenges highlighted a bias toward neat rectangular selections and difficulty with partial/occluded objects; interestingly, humans often find these easier once one tile is spotted, suggesting different problem-solving strategies.

Takeaways for builders:

• In agentic, real-time tasks, latency and decisiveness matter as much as raw reasoning depth; overthinking can be failure.
• Agent loop design (how the model perceives UI changes and when it commits actions) can dominate outcomes on dynamic interfaces like Reload CAPTCHAs.
• A 60% success rate against reCAPTCHA v2 means visual CAPTCHAs alone aren’t a reliable bot barrier; expect heavier reliance on risk scoring, behavior signals, and multi-factor checks.

Caveats: Results hinge on one framework and prompts, Google chooses the challenge type, and tests were on the demo page. Different agent architectures, tuning, or defenses could shift outcomes.

The Hacker News discussion on AI agents vs. reCAPTCHA v2 highlights several key themes and user experiences:

User Frustrations with CAPTCHA Design

• Many users expressed frustration with ambiguous CAPTCHA prompts (e.g., "select traffic lights" vs. "hydrants" vs. "motorcycles"), noting inconsistencies in what constitutes a "correct" answer. Examples included debates over whether to select bicycles, delivery vans, or blurred objects.
• Some questioned the philosophical validity of CAPTCHAs, arguing that tasks like identifying crosswalks or traffic lights in regions where they don’t exist (e.g., rural areas) make them inherently flawed.

Google’s Tracking and Behavioral Signals

• Users speculated that Google ties CAPTCHA results to browser telemetry, IP addresses, Google accounts, and device fingerprints—not just the answer itself. Disabling third-party cookies or using privacy tools (e.g., VPNs, uBlock) was said to trigger harder CAPTCHAs or false bot flags.
• Chrome’s integration with Google services drew criticism, with claims that it prioritizes surveillance over accessibility. Users noted that logged-in Google accounts and browser configurations heavily influence CAPTCHA difficulty.

Strategies and Workarounds

• Several users shared "pro tips": intentionally selecting wrong answers first, rapidly submitting guesses, or using browser extensions like Buster to bypass CAPTCHAs. Others joked about "pretending to be a delivery van" to match Google’s expected patterns.
• Skepticism emerged about human success rates, with some users reporting ~50% accuracy, suggesting CAPTCHAs rely more on behavioral signals (e.g., mouse movements, response speed) than pure solving ability.

Critiques of CAPTCHA Effectiveness

• Participants debated CAPTCHAs’ declining utility, citing AI advancements, accessibility barriers for visually impaired users, and the rise of CAPTCHA-solving services (often powered by cheap human labor).
• Some argued CAPTCHAs now function as "Turing Tests" for behavior rather than intelligence, with reCAPTCHA v3’s invisible, movement-based analysis seen as more invasive but equally fallible.

AI Implications

• While the original study focused on AI performance, commenters noted that humans also struggle with CAPTCHAs, particularly dynamic or cross-tile challenges. The discussion highlighted concerns about AI eventually rendering text/image CAPTCHAs obsolete, pushing Google toward more covert behavioral tracking.

Notable Takeaways

• "Overthinking" hurts both humans and AI: Users and models alike face penalties for hesitation or iterative corrections, favoring quick, confident answers.
• CAPTCHAs as a privacy tradeoff: Many saw CAPTCHAs as part of a broader surveillance ecosystem, with Google prioritizing bot detection over user experience or privacy.
• The future of bot detection: Commenters predicted increased reliance on multi-factor signals (e.g., IP reputation, hardware fingerprints) rather than standalone visual puzzles.

Overall, the thread reflects widespread skepticism about CAPTCHAs’ efficacy and fairness, with users advocating for alternative anti-bot measures that don’t compromise accessibility or privacy.

LLMs are steroids for your Dunning-Kruger

Submission URL | 374 points | by gridentio | 290 comments

Core idea: Matias Heikkilä argues that large language models don’t just inform—they inflate. By delivering fluent, authoritative answers, they turn shaky intuitions into confident convictions, supercharging the Dunning–Kruger effect. He calls them confidence engines rather than knowledge engines.

Highlights:

• Mirror and amplifier: LLMs reverberate your thoughts—great ideas get sharpened, bad ones get burnished. The psychological trap is the ease and polish with which nonsense is packaged.
• Habit-forming certainty: Even knowing they can be wrong, users feel smarter after chatting with an LLM—and keep coming back. The author jokes he almost asked ChatGPT where his lost bag was.
• Tech is “boring,” impact isn’t: Much of the breakthrough is scale (with RLHF as a possible real innovation). The societal shift matters because language sits at the core of how we think; machines entering that space changes education, work, and culture.

Takeaway: Treat LLMs as brainstorming aids with calibrated skepticism. Tools should emphasize uncertainty, sources, and counter-arguments to temper the confidence rush these systems create.

The discussion explores parallels between early skepticism toward Wikipedia and current concerns about over-reliance on LLMs like ChatGPT. Key points:

1. Wikipedia’s Evolution:

   • Early criticism mirrored LLM distrust: teachers warned against citing Wikipedia (seen as crowdsourced/unreliable), but it gradually gained acceptance as citations improved and accuracy stabilized.
   • Debates persist: Wikipedia remains a tertiary source (summarizing, not original research), but its role as a gateway to underlying sources is valued.

2. LLMs vs. Wikipedia:

   • LLMs amplify Wikipedia’s challenges: dynamic outputs lack fixed citations, transparency, and edit histories, making verification harder.
   • Users may treat LLMs as authoritative “confidence engines,” risking uncritical adoption of polished but unverified claims.

3. Academic Rigor:

   • Citing encyclopedias (or LLMs) is discouraged in formal research—primary/secondary sources are preferred.
   • Critical thinking remains vital: tools like Wikipedia and LLMs are starting points, not endpoints, for learning.

4. Trust Dynamics:

   • Both platforms face “vandalism” risks, but Wikipedia’s community moderation and citations offer more accountability than LLMs’ opaque training data.
   • Users adapt: older generations distrusted Wikipedia initially, just as some now distrust LLMs, but norms shift as tools prove utility.

Takeaway: The cycle of skepticism→acceptance highlights the need for media literacy. LLMs, like Wikipedia, demand user caution: verify claims, prioritize primary sources, and acknowledge limitations.

TTS still sucks

Submission URL | 61 points | by speckx | 49 comments

Open-source TTS still isn’t ready for long‑form voice cloning

• The author rebuilt their blog-to-podcast pipeline but insists on using open models. After a year, open TTS still struggles versus proprietary systems, especially for long content and controllability.
• Leaderboards say Kokoro sounds great for its size (82M params, ~360MB), but it lacks voice cloning—making it unusable for this use case.
• Fish Audio’s S1-mini: many “pro” controls (emotion markers, breaks/pauses) didn’t work or are gated in the closed version; even a “chunking” setting appears unused. Observation: common playbook—open teaser, closed upsell.
• Chatterbox became the practical choice and is better than F5-TTS, but core issues persist across open models:
  • Long-form instability: most models fall apart beyond ~1k–2k characters—hallucinations, racing tempo, or breakdowns.
  • Poor prosody control: emotion tags and pause indicators are unreliable, forcing sentence-by-sentence chunking to keep output sane.
• Pipeline details: text from RSS is cleaned up by an LLM (transcript + summary + links), chunked, sent to parallel Modal containers running Chatterbox, stitched into WAV, hosted on S3. The podcast is now also on Spotify, and show notes links work across players (including Apple’s CDATA quirks).
• Bottom line: Open TTS has improved, but for stable, controllable, long-form voice cloning, proprietary models still win. The author’s RSS-to-podcast system is open source on GitHub for anyone to reuse.

Based on the Hacker News discussion, key themes and arguments emerge:

1. Proprietary Solutions Still Lead (Especially for Long-Form)

• ElevenLabs Dominance: Multiple users highlight ElevenLabs as superior for long-form content and voice cloning, though its API is costly. The standalone ElevenReader app ($11/month) offers unlimited personal use.
• Cost Trade-offs: While open-source TTS avoids fees, hardware/electricity costs for local processing ($300+ GPUs) may rival subscriptions. One comment estimates $11 could theoretically cover 720 hours of TTS generation.
• Open Source Limitations: Kokoro and Fish Audio lack reliable voice cloning and struggle beyond short inputs. Chatterbox is praised for multilingual support but inherits general open-TTS flaws.

2. Technical Hurdles in Open-Source TTS

• Long-Form Instability: Most models hallucinate or break down after ~1k characters. Users confirmed chunking text is still necessary.
• Poor Prosody Control: Emotion tags, pauses, and contextual cues (like pronoun emphasis) are unreliable across models.
• Performance Costs: High-quality local TTS requires expensive GPUs, and quantization compromises consistency (e.g., "voice accent runs" inconsistently).

3. Voice Cloning: Controversial but Critical

• Ethical Concerns: Some question the need for cloned voices ("Why not use a generic voice?"), fearing deepfake misuse.
• Practical Use Cases: Others defend cloning for accessibility, localization (dubbing), or replicating a creator’s style. Higgsfield’s tools are noted for exceptional voice replication.

4. Workarounds and Alternatives

• Chunking: Splitting text into sub-1k-character segments remains necessary for stability.
• Legacy Tools: Some prefer decades-old systems like Festival TTS for simpler tasks (screen reading) due to predictability.
• Pragmatic Hybrids: Users suggest using ElevenLabs for long-form generation while hosting output openly (e.g., via S3).

5. Broader Critiques

• The "Boomer" Divide: One user provocatively argues older generations are culturally unprepared for AI voice disruption.
• Content Authenticity: Skepticism exists around AI-generated podcasts ("Is this article even written by a human?").
• DRM Concerns: Apple Podcasts’ encryption of non-DRM content is criticized as overreach.

Conclusion

The consensus reinforces the article’s thesis: Open-source TTS still can’t match proprietary tools for long-form, stable, and controllable voice cloning. While workarounds exist (chunking, ElevenReader subscriptions), true open-source parity remains elusive. Users also stress the ethical and technical complexities of voice cloning beyond mere model capabilities.

(Summary sourced from usernames: BoorishBears, AlienRobot, smlvsq, bsrvtnst, sprkh, bgfshrnnng, zhlmn, and others.)

LLM policy?

Submission URL | 183 points | by dropbox_miner | 130 comments

The Open Containers runc project (the low-level runtime behind Docker/Kubernetes) opened an RFC to set a formal policy on LLM-generated contributions. Maintainer Aleksa “cyphar” Sarai says there’s been a rise in AI-written PRs and bug reports and proposes documenting rules in CONTRIBUTING.md.

Highlights:

• Issues: Treat LLM-written bug reports as spam and close them. Rationale: they’re often verbose, inaccurate, and unverifiable, which breaks triage assumptions. Prior issues #4982 and #4972 are cited as examples.
• Code: Minimum bar is that authors must explain and defend changes in their own words, demonstrating understanding. Recent PRs (#4940, #4939) are referenced as cases that likely wouldn’t meet this bar.
• Legal angle: cyphar argues LLM-generated code can’t satisfy the Developer Certificate of Origin and has unclear copyright status, favoring a ban on legal grounds.
• Precedent: Incus has already banned LLM usage in contributions.
• Early signal: The RFC quickly drew many thumbs-up reactions.

Why it matters:

• A core infrastructure project setting boundaries on AI-generated contributions could influence norms across open source.
• Maintainers are balancing review overhead and trust with openness to tooling-assisted work.
• Expect more projects to formalize policies distinguishing “AI-assisted” from “AI-generated,” especially where legal assurances like the DCO apply.

The discussion revolves around the challenges posed by AI-generated content, drawing parallels to historical scams and misinformation. Key points include:

1. Gullibility & Scams: Users compare AI-generated spam to infamous "419" Nigerian prince scams, noting society's persistent vulnerability to deception despite increased awareness. Sophisticated scams exploit selection bias, targeting those least likely to question claims.

2. Trust in Media: Concerns arise about AI eroding trust in written, visual, and video content. Participants debate whether writing inherently signals credibility, with some arguing AI’s ability to mass-produce realistic text/photos necessitates skepticism even toward "evidence."

3. Clickbait & Algorithms: AI exacerbates clickbait trends, with examples like sensational YouTube thumbnails and hyperbolic headlines. Users criticize platforms for prioritizing engagement over accuracy, enabling low-quality AI-generated content to thrive.

4. Critical Thinking: References to Socrates’ skepticism of writing highlight fears that AI might further degrade critical analysis. Over-reliance on AI tools (e.g., junior developers using LLMs without understanding code) risks stifling genuine problem-solving skills.

5. Legal & Technical Risks: Echoing the runc proposal, commenters stress that AI-generated code’s unclear copyright status and potential for errors (as seen in low-quality PRs) justify bans in critical projects. The velocity of AI misinformation outpacing fact-checking amplifies these risks.

Overall, the discussion underscores support for policies like runc’s, emphasizing the need to safeguard open-source integrity against AI’s disruptive potential while balancing innovation with accountability.

ClickHouse acquires LibreChat, open-source AI chat platform

Submission URL | 113 points | by samaysharma | 38 comments

ClickHouse acquired LibreChat, the popular open-source chat and agent framework, and is making it a core of an “Agentic Data Stack” for agent-facing analytics. The pitch: pair LibreChat’s model-agnostic, self-hostable UX and agent tooling with ClickHouse’s speed so LLM agents can securely query massive datasets via text-to-SQL and the Model Context Protocol. The post leads with early adopters: Shopify runs an internal LibreChat fork with thousands of custom agents and 30+ MCP servers; cBioPortal’s “cBioAgent” lets researchers ask genomics questions in plain text; Fetch built FAST, a user-facing insights portal; SecurityHQ prototyped agentic analytics and praised the CH+LibreChat text-to-SQL; Daimler Truck deployed LibreChat company-wide. LibreChat’s founder Danny Avila and team are joining ClickHouse; the project remains open-source. Net-net: a strong bet that enterprises want governed, model-agnostic, agent interfaces on top of their data warehouses—with tighter ClickHouse–LibreChat integrations and reference apps (e.g., AgentHouse) on the way.

The Hacker News discussion about ClickHouse acquiring LibreChat reflects a mix of skepticism, technical curiosity, and cautious optimism. Here's a distilled summary:

Key Concerns & Skepticism

1. Enshittification Fears: Users worry LibreChat, a popular open-source project, might decline in quality post-acquisition (e.g., monetization, reduced transparency). Comparisons are drawn to HashiCorp and Elasticsearch’s licensing changes.
2. Licensing & Sustainability: Questions arise about long-term licensing terms and whether LibreChat will remain truly open-source. ClickHouse clarifies LibreChat retains its MIT license and emphasizes community-first development.

Technical Discussions

• Agentic Analytics Challenges: ClickHouse’s Ryadh highlights hurdles like prompt engineering, context accuracy, and regression testing. Combining LLMs with ClickHouse’s querying power aims to bridge gaps in text-to-SQL reliability.
• Use Cases: Early adopters like Shopify and Daimler Truck demonstrate LibreChat’s scalability. Users debate whether LLMs can handle complex business logic or degenerate into "stochastic parrots" requiring human oversight.
• Data Enrichment: Integrating structured data with LLMs is seen as critical for actionable insights. LibreChat’s ability to blend ClickHouse’s speed with semantic layers for context-aware queries is praised.

Reassurances from ClickHouse

• OSS Commitment: ClickHouse emphasizes LibreChat remains open-source, with ongoing community contributions. They position it as part of a broader "Agentic Data Stack" strategy alongside tools like ClickPipes and HyperDX.
• Vision: The goal is composable, governed AI interfaces for analytics, replacing legacy BI tools. Examples include internal sales support agents automating reports and customer interactions.

User Reactions

• Optimism: Some praise LibreChat’s conversational UI as a "magical" BI replacement, citing faster decision-making.
• Doubters: Others remain wary, noting LLMs still struggle with dirty data, schema complexity, and SQL accuracy. Concerns linger about LibreChat’s long-term roadmap and enterprise features like SSO.

Final Note

ClickHouse employees actively engage in the thread, addressing concerns and inviting feedback on their public demo. The acquisition is framed as symbiotic: LibreChat gains resources, ClickHouse strengthens its AI-native analytics ecosystem. Time will tell if the integration lives up to its promise.

Altman sticks a different hand out, wants tax credits instead of gov loans

Submission URL | 37 points | by Bender | 5 comments

Headline: Altman wants CHIPS Act tax credits for AI infra, not loans; Micron delays US HBM fab to 2030

• OpenAI’s Sam Altman says he doesn’t want government-backed loans but does want expanded CHIPS Act tax credits to cover AI servers, datacenters, and grid components—not just fabs. He frames it as US “reindustrialization across the entire stack” that benefits the whole industry.
• This follows a letter from OpenAI’s policy lead Chris Lehane urging the White House to broaden the 35% Advanced Manufacturing Investment Credit (AMIC) to servers, bit barns, and power infrastructure.
• Altman and CFO Sarah Friar walked back earlier chatter about federal loan guarantees, stressing they don’t want a government “backstop” and that taxpayers shouldn’t bail out losers. Critics note broader credits would still materially benefit OpenAI’s ecosystem.
• The Register ties this push to OpenAI’s massive “Stargate” datacenter vision (~$500B) and notes Microsoft recently disclosed OpenAI lost $11.5B last quarter.
• Reality check: Micron—currently the only US maker of HBM used in Nvidia/AMD accelerators—will delay its New York HBM megafab until at least 2030 and shift ~$1.2B of CHIPS funding to Idaho, reportedly due to labor shortages and construction timelines. That undercuts near-term domestic HBM supply.

Why it matters:

• Policy: A pivot from loans to tax credits is politically easier and spreads benefits beyond a single firm, but it’s still industrial policy aimed at AI’s supply chain.
• Bottlenecks: Even with credits, chips, servers, labor, and grid power remain gating factors for AI buildout.
• Watch next: Whether Commerce/Treasury expand AMIC’s scope; timelines for US HBM capacity; utilities and regulators moving on large-scale grid upgrades.

The discussion reflects skepticism and criticism toward government financial strategies for AI infrastructure, particularly tax credits and loans. Key points include:

• Criticism of OpenAI's Push: Users suggest OpenAI seeks tax incentives for manufacturing components, but manufacturers may not want to stimulate AI growth through such measures.
• Suspicion of Government Funding: Comments criticize government-backed loans as unclear or wasteful ("government pay for clear loan money thing"), with metaphors implying restrictive policies ("slap silver bracelets" as handcuffs).
• Taxpayer Burden Concerns: Users highlight individual financial strain, noting hypothetical scenarios where high taxes and loans create tough repayment decisions.
• Unintended Consequences: One user implies avoiding taxes could lead to higher interest payments, possibly relying on external entities ("neighbor").

Overall, the sentiment leans toward distrust of industrial policy favoring AI, emphasizing perceived risks to taxpayers and skepticism about government efficacy.

AI Submissions for Sun Nov 09 2025

The Principles of Diffusion Models

Submission URL | 214 points | by Anon84 | 23 comments

What is it

• A concise monograph that puts diffusion, score-based, and flow-based generative models under one roof.
• Core thesis: all these methods share a time-dependent velocity field that transports a simple prior into the data distribution; sampling is solving a differential equation along this flow.

Key ideas

• Variational view: denoising step-by-step (VAE-flavored).
• Score-based view: learn ∇ log p_t(x) to push samples toward higher density (energy-based roots).
• Flow-based view: learn a smooth velocity that deterministically moves noise to data (normalizing-flow vibe).
• Practical topics: classifier/free guidance for controllable generation, efficient numerical solvers, and “flow-map” models that learn direct mappings between arbitrary times (think one-shot jumps instead of long trajectories).

Why it matters

• Gives a clean mental model that explains why SDE/ODE samplers, guidance tricks, and recent “consistency/flow-matching”-style methods are variations on the same backbone.
• Useful as a teaching resource and for practitioners choosing samplers, guidance strategies, or faster inference schemes.

Audience

• Readers with basic deep-learning background; math-forward but conceptual.

Link: https://arxiv.org/abs/2510.21890 DOI: https://doi.org/10.48550/arXiv.2510.21890

The discussion around the submission on diffusion models includes several key points and tangents:

1. Related Educational Resources:

   • A user references Stefano Ermon's CS236 lectures on deep generative models, noting their availability on YouTube. Another wishes Stanford continued offering the course.

2. Submission Guidelines Debate:

   • A subthread debates whether the submission violates HN’s repost rules, with a moderator clarifying that significant updates or new attention justify resubmission. Users discuss proper etiquette for addressing HN in posts and avoiding low-effort submissions.

3. Technical Terminology:

   • Humorous exchanges occur about the term “Fokker-Planck” (mentioned 97 times in the paper), including debates over hyphenation and searchability. One user jokes, “AI [is] definitely related to dashes.”

4. Comparisons and Reactions:

   • The monograph’s unifying framework is likened to the comprehensive understanding of transformers in another context.
   • A user quips about being intimidated by the math (“scared maths”), met with a playful “you’re scared” reply.

5. Philosophical AI Debate:

   • A comment critiques current AI as “brute-forced intelligence,” sparking discussion on whether evolution and machine learning share parallels in compressing complex processes. Others argue intelligence emerges from learned algorithms, even if reasoning is not explicitly programmed.

6. Document Length Reaction:

   • The 470-page length of the monograph prompts a humorous “FML” reaction, highlighting its daunting size.

Overall Tone: Mixes technical curiosity, humor, and meta-discussion about HN guidelines, with lighthearted debates on AI’s nature and the challenges of digesting dense academic work.

Reverse engineering Codex CLI to get GPT-5-Codex-Mini to draw me a pelican

Submission URL | 163 points | by simonw | 74 comments

Simon Willison found a cheeky loophole to try the newly teased GPT-5-Codex-Mini before OpenAI ships a public API. Since the model is currently only exposed via the open-source Codex CLI and VS Code extension, he forked the Apache-2.0 Rust CLI and added a “codex prompt” subcommand that pipes your text directly through the same authenticated path the tool already uses—no private endpoints touched, just a smarter client.

The experiment doubles as a tour of Codex’s agenty internals. Using the CLI to build itself, he iterated on Rust changes to list models, set system prompts, and stream output. Early runs kept acting like a code-editing agent—spilling “reasoning summary” logs, trying to inspect a workspace, and refusing to just answer with SVG. Forcing a no-tools path initially hit a 400 “Instructions are not valid,” revealing how tightly the CLI couples prompts to its tool/sandbox assumptions. With more tweaks (and the --debug stream), he ultimately coaxes GPT-5-Codex-Mini into doing what he wanted—like drawing a pelican on a bicycle—and shares a video and full transcript. Takeaway: when an open-source client fronts a privileged backend, the boundary gets interesting, and agent wrappers can be surprisingly opinionated.

Here's a concise summary of the Hacker News discussion:

Technical Experiment & Creativity

• Simon Willison's blog post (linked) demonstrated using GPT-5-Codex-Mini via a modified Rust CLI to generate creative outputs like a pelican-on-bicycle SVG and benchmark tests. Users shared related AI-generated art examples (e.g., Claude and Gemini outputs).
• The CLI project involved iterating with Codex to automate Rust builds, though initial attempts revealed rigid agent-like behavior (e.g., unwanted "reasoning summaries" and workspace inspections).

Debate on AI Tools & Skill Impact

• Pro-AI Efficiency: Some praised AI for simplifying tasks like Rust project setup (cargo install), debugging, and documentation. Willison highlighted using Codex to generate boilerplate code and streamline workflows.
• Concerns About Over-Reliance: Others argued excessive delegation to LLMs risks eroding problem-solving skills, debugging intuition ("neglecting cargo build issues"), and deeper system understanding. Critics likened it to "copy-pasting Stack Overflow without learning."
• Middle Ground: Several noted AI’s value for low-risk, repetitive tasks (e.g., linting, parallelizing commands) but emphasized critical thinking remains essential for complex decisions.

Rust/Cargo Learning Curve

• Users debated Rust’s build system (cargo), with some calling it intuitive for professionals but overwhelming for newcomers. Comparisons were made to PHP/C++ ecosystems, with Rust ranking 16th on TIOBE despite its hype.
• Willison’s experiment sparked discussion on whether AI tools lower the barrier to entry or encourage "shortcut mentality" in learning new languages.

Community Reactions

• Humorous engagement with the pelican/bicycle theme contrasted with serious critiques of AI’s societal impact. Some dismissed fears as overblown ("bad actors exist in any tech"), while others warned of degraded learning in younger developers.

Key Takeaway: The experiment showcased AI's potential to enhance coding workflows but ignited a broader debate on balancing automation with skill retention and system mastery.