LLMs reward expertise
LLMs let anyone generate usable code or text, leading to the perception that prompting requires no skill. The post argues that true prompting effectiveness depends on deep domain expertise. It cites Terence Tao’s interaction with ChatGPT on the Jacobian Conjecture, highlighting how Tao’s concise, expert‑driven messages steer the model into a “mathematician” mode, push back on implausible outputs, and make independent leaps rather than following the model’s suggestions. The author notes that such technique works only because Tao understands the underlying mathematics and can extract relevant ideas, evaluate correctness, and reformulate problems. The same principle applies to software: familiarity with a codebase lets users critique, simplify, or rephrase prompts, extracting higher‑quality results. Consequently, human expertise remains the bottleneck; the model stores information, but a knowledgeable user must communicate precise goals to retrieve it. Community comments on Hacker News echo these points, acknowledging both the plausibility of the claim and the need for expert validation in specialized domains.
Show HN: Run an 80B Qwen in 4.3 GB of RAM on a Mac, and a 35B on an iPhone
Swiftlet is a Swift + Metal runtime that enables Qwen3‑Next and Qwen3.5/3.6 Mixture‑of‑Experts (MoE) models (35 B and 80 B) to run on Apple Silicon devices, including iPhones. It retains only the dense core (attention, DeltaNet projections, routers, shared experts, embeddings) in RAM—≈1.3 GB (35 B) or 2.5 GB (80 B) at 4‑bit quantization—while streaming routed expert weights from SSD on demand via a fixed‑stride .qpack container. Each token activates ≈3 B parameters: the 35 B model routes to 8 of 256 experts, the 80 B to 10 of 512. A bounded LFU + recency cache mitigates miss penalties; Apple SSDs absorb the remaining latency. The forward pass runs entirely on Metal with runtime‑compiled shaders, using Gated DeltaNet linear attention (no growing KV cache). Swiftlet provides:
- Swift package (SwiftletCore) for macOS/iOS integration
- CLI tools (
swiftlet chat,swiftlet generate,swiftlet-repack) - Loopback OpenAI‑compatible server (
swiftlet-server) - Open‑source iOS app (Priv AI) for on‑device chat
Models validate against mlx‑lm reference implementations; the project builds on ~10 k lines of Swift/Metal and is Apache 2.0 licensed. Requirements: Apple Silicon, macOS 14+/iOS 17+, 18 GB (35 B) or 42 GB (80 B) SSD space.
The comments express optimism that continued engineering will eventually enable large language models to run on modest consumer hardware, while also noting current limitations such as slow processing speeds, heavy reliance on disk swapping, and potential wear on storage devices. Readers seek clearer information about collaboration claims and desire configurable memory usage to exploit available RAM. Overall, there is enthusiasm for future efficiency gains but frustration with present performance bottlenecks and hardware strain.
Amazonian civilization had estimated 3M people in 3% of forest area
The comments highlight recent lidar research that challenges the notion of an untouched Amazon, indicating that pre‑colonial peoples extensively modified the forest. They note that this reshapes understanding of ancient Amazonian societies and underscores the limited archaeological record. The discussion also references significant recent forest loss and conversion to agriculture, while emphasizing the catastrophic impact of Old‑World diseases on indigenous populations and the resulting disappearance of complex settlements described by early explorers.
Ten advances in mathematics and theoretical computer science
The discussion acknowledges impressive AI‑generated proofs and sees them as a clear technical advance, but opinions diverge on their broader significance. Many view the results as evidence of rapidly improving capability, yet question whether they represent genuine insight, novel mathematics, or merely exhaustive search, and call for more transparency about methodology, costs, and reproducibility. Concerns are raised about the impact on academic credit, future research directions, practical applications, and potential displacement of human expertise, while some remain cautiously optimistic about longer‑term benefits.
Devtools must be open source
The post argues that modern AI agents make personalizing software as easy as editing source code, eliminating the need for extensive configuration, plugins, or large upfront development costs. Two simple prompts enable an agent to (1) download, build, and track changes to a program’s source, and (2) automatically rebase local modifications onto upstream updates via a nightly cron job. Because agents can understand and modify code, personalization no longer requires programming expertise; users can issue natural‑language commands (e.g., “make Shelley’s UI high‑contrast”) and the agent applies the change. The author illustrates this with “meat.dev,” a tool that uses LLMs to filter diffs, integrated into the Shelley IDE via a single prompt that installs the tool, runs it on each git commit, and adds a UI toggle. This agent‑driven workflow is presented as superior to traditional extension APIs (e.g., VS Code, vimdiff) because the agent handles source‑level changes automatically. Consequently, the author contends that all software—especially single‑user or small‑team products—should be open source and directly personalizable, as closed‑source agents like Claude Code lack this flexibility.
The discussion acknowledges that large language models reduce the effort needed to explore and adapt open‑source code, making occasional inspection more practical, yet most participants doubt that everyday personalization through full recompilation is efficient or sustainable. Concerns dominate around maintenance burdens, reliability of automated merges, loss of stable tooling, and the business challenges of open‑source devtools when AI can generate comparable versions. While many still value open‑source transparency and modular plugins, opinions split between optimism about new AI‑enabled workflows and skepticism about their practicality, cost, and long‑term trust.
Ask HN: Who is hiring? (August 2026)
The collection highlights a strong focus on AI‑driven technologies across hardware design, security scanning, and personal‑assistant platforms, with multiple startups seeking engineers, product managers, and technical marketers. Remote and hybrid roles dominate, emphasizing flexibility, high‑impact contributions, and small‑team autonomy, while several positions stress expertise in machine learning, detection systems, and low‑level systems programming. Compensation ranges vary widely, often including equity, and many postings stress execution, user‑experience focus, and collaboration with experienced, technically sophisticated teams.
There Will Come Soft Rains (1950) [pdf]
Comments highlight the story’s bleak yet resonant portrayal of technology outlasting humanity, with many noting its relevance to climate anxiety and modern automation. Several users reference adaptations, audio readings, and musical works inspired by the piece, indicating ongoing cultural impact. Opinions on Bradbury’s prose are divided, some praising its haunting quality while others find it overly ornate compared to more minimalist writers. Overall the discussion emphasizes the narrative’s enduring emotional power and its connections to contemporary concerns.
IPC-7351B Electronic Component Zero Orientation [pdf]
Comments express frustration with inconsistent component orientation, noting that pin 1 placement varies and components are often randomly positioned, making full automation difficult. The prevailing advice is to adopt a single convention—either upper‑left or lower‑left—for library entries and adhere to it. Manual verification, especially for WS2812/WS2816 LEDs, remains necessary, as manufacturers frequently request orientation confirmation, reflecting broader dissatisfaction with LED handling and a general dislike for LEDs.
Smaller, faster, safer: running Kimi and GLM at scale
Cloudflare Workers AI serves large, long‑context mixture‑of‑experts models (Moonshot’s Kimi K‑series and Z.ai’s GLM) on GPUs near users. To fit these models in memory while maintaining speed, three optimizations are layered on top of the existing prefill‑decode separation:
-
KV‑cache quantization – the attention key/value cache is stored in 8‑bit floating‑point (FP8, e4m3) instead of BF16, halving its size. On Kimi K2.6 this doubles usable context (≈686 k → 1.37 M tokens) and raises concurrent‑request throughput from a BF16 peak of 1.56 k t/s (32 requests) to 2.19 k t/s at 64 requests, a ~41 % increase with ~30 % lower cost per token. Accuracy across GSM8K, ARC, MMLU, and tool‑call tests is indistinguishable.
-
Weight compression – GLM 5.2 weights are reduced from 8‑bit to 4‑bit integers (INT4) without accuracy loss, shrinking the checkpoint 40 % (705 GB → 421 GB) and dropping per‑GPU memory from 88 GB to 52 GB. Decode throughput gains of 16‑55 % are observed (e.g., 60 t/s → 92 t/s at single‑request concurrency). Prefill remains faster with FP8 weights due to compute‑bound nature, so the system uses INT4 for decode and FP8 for prefill.
-
KV‑cache integrity checks – each physical cache page is tagged; requests’ expected page/tag mappings are verified before decode reads. The safety layer adds <1 % overhead to throughput and 95th‑percentile latency.
All experiments run on the SGLang inference framework. Ongoing work includes expanding FP8 caches fleet‑wide, testing NVFP4 weights on NVIDIA Blackwell GPUs, and further reducing integrity‑check cost. These techniques enable higher request density, lower operating cost, and unchanged model quality.
Comments recognize the provider’s openness about KV‑cache quantisation but critique the limited testing, noting only a single model was evaluated and that benchmarks omit coding or long‑running tasks where degradation may appear. Users express distrust over undisclosed pricing, privacy worries linked to Cloudflare’s infrastructure, and the omission of quantisation details on model pages, calling it potentially misleading. Technical concerns include preference for more efficient 4‑bit formats and a desire for deeper performance analysis, while some readers find the material overly dense.
Apple is getting this wrong
Comments convey strong criticism of OpenAI, portraying it as fearful, opportunistic, and reliant on alleged data misuse. Observers note the company's public blog post on ongoing litigation as atypical, PR‑driven, and potentially counterproductive, questioning the practice of using personal iCloud accounts for work at both Apple and OpenAI. The lawsuit is seen as unsurprising given past behavior, with expectations that the case will proceed to discovery and trial rather than being won through public opinion.
The comments emphasize that large language models are effective when users possess domain knowledge and can formulate precise prompts, while novices often encounter confusion and unproductive loops. Many view the models as accelerators that extend expertise rather than replacements for deep understanding, noting that guidance and contextual awareness remain essential. Concerns arise about potential erosion of hands‑on learning and the risk of over‑reliance on AI, yet there is consensus that, when used skillfully, the technology functions as a powerful tool rather than a universal solution.