Llms

Political theorist Gregory Conti (Princeton, writing in Compact) makes the strongest recent statement of the “AI is not the steam engine” case from the conservative side. His central move: AI opposition is misdirected because it targets future risks when generative AI is already producing moral and cultural harm. Anthropomorphic AI — models that mimic personality, emotion, and thought — is unsettling human psychology and the social fabric right now, so opposition should target what AI is, not only what it may become. The sui generis argument is the essay’s sharpest contribution: past innovations substituted for material processes; AI substitutes for language and cognition themselves — the things that constitute human distinctiveness — so the Luddite analogy is a category error. From there he prosecutes the case across four fronts: capitalism will be destroyed by its own success (quoting Marx’s prediction that production based on exchange value breaks down once machines out-produce labor, and noting Dario Amodei’s “Machines of Loving Grace” is fully automated luxury communism — the anti-communists may prove Marx right); individualism dies as AI becomes a homogenizer whose answers are statistical averages of human speech (Tocqueville’s soft despotism, Mill’s warning in On Liberty); democracy fails once citizens have no economic or military value, becoming subjects rather than rights-bearers; and the written word loses its human provenance — his grandmother’s-letters thought experiment: if she’d had Gemini, the access to the real person is denied forever. The essay also lands a sharp critique of AI-booster “productivity”: reading fifty papers in a month is really not reading fifty papers — you emerge with a facsimile minus the understanding, a slightly different person than the one who would have done the work. The prescription is uncompromising: not regulation but rejection — limit the diffusion of anthropomorphic AI in civil society and end the pursuit of superintelligence. Read it alongside the Cognitive Commons paper: same underlying claim (the cognitive labor itself is the product being destroyed), argued from political philosophy instead of labor economics. ...

Nolan Lovett’s conceptual paper (Human Resource Development Review, 2026) applies Garrett Hardin’s Tragedy of the Commons to professional expertise: each organization’s rational decision to replace entry-level cognitive labor with AI is locally sensible, but collectively it depletes the shared pool of deep human expertise that every organization in the profession depends on — especially for validating AI output. The key constructs: Internalized Mastery (deep domain knowledge built through sustained cognitive struggle) vs. Distributed Mastery (orchestrating human-AI systems), connected by the Validation Tether — effective AI oversight fundamentally depends on the very expertise AI adoption can undermine. Evidence is already visible in the cohort data: in AI-exposed occupations, employment for workers aged 22-25 fell 16% (Oct 2022 - Sep 2025) while workers 35-49 grew 8%+, exactly the pattern commons depletion through foreclosed regeneration predicts. The paper distinguishes surface validation (spotting obvious errors — no domain expertise needed) from substantive validation (recognizing plausible-but-wrong output — requires deep knowledge), and warns that as workers lose the cognitive struggle that builds mastery, they gain productivity on routine tasks while losing the ability to catch AI’s failures on non-routine ones. The argument borrows Hardin’s structure but not his fatalism — Ostrom showed commons can be sustained with governance at organizational, professional-association, and policy levels. The sharpest insight: the pre-AI equilibrium was never governed — developmental pipelines were maintained because organizations needed junior labor, and AI breaks that accidental alignment. ...

Michael Fogus’s short essay on why hobby programming communities — chess-engine devs, OSDev, EmuDev, the demoscene, code golfers — are aggressively hostile to LLM usage. The surface complaint is that LLM-generated code “misses the point entirely,” but the point is deeper: in these communities the process of mastering a difficult field is the product, and something that runs is a nice-to-have. Respect is earned slowly — years of forum activity, elegant code, displays of genuine curiosity, deep domain knowledge — and nobody cares whether your code works so much as whether you know why and how it works. Fogus traces how earnest early LLM engagement got poisoned fast, by practitioners who lacked deep understanding and by a vitriolic subset who view the whole enterprise as cheating. His own position is measured: an LLM is a force multiplier, not a surrogate — in the hands of an expert who already understands a domain, it acts like a lever, though he warns that expertise offers no natural immunity against being fooled. The closing line lands the thesis: using an LLM to generate the finished piece doesn’t make us craftsmen; it just robs us of the craft. Read it next to “Don’t Be a Meat Proxy” — both are really about what happens when the tool does the work and the human stops doing the learning. ...

Tom Zahavy’s ICML 2026 position paper makes a sharp claim about where LLMs actually stop: they can induce and they can deduce, but they can’t abduce. Using Einstein’s 1952 letter to Maurice Solovine as the frame, Zahavy maps scientific discovery as a cycle — sense experience, an intuitive “jump” to axioms, then logical deduction from those axioms. LLMs, he argues, have mechanized the last part (formal proof, à la AlphaProof) and the statistical pattern-matching of induction, but the generative step — the abductive leap that produces a genuinely new axiom from scarce or absent data — is structurally out of reach. The case study is the equivalence principle: Einstein didn’t derive general relativity by compressing data, because Newtonian physics faced no empirical crisis (the one anomaly, Mercury’s perihelion, was explained away with the hypothetical planet Vulcan). With no error signal, “creativity as compression” has no gradient to push a system toward restructuring spacetime. The fix isn’t a bigger LLM: Zahavy proposes action-controllable, physically consistent world models — synthetic laboratories where an agent can intervene counterfactually, cut the elevator cable, and ground symbols in simulated sensation. It’s a position argument, not a proof — reviewers pushed the conclusion from “confirms” to “suggests” — but it’s a genuinely provocative frame for what “AI for science” can and cannot mechanize. ...

Sean Goedecke pushes back on the idea that LLMs make everyone a generalist and that “prompting skill” is a myth. The real differentiator, he argues, is domain expertise. His proof point is Terence Tao’s conversation with ChatGPT about the Jacobian Conjecture counterexample — Tao’s prompts are short, precise, and push back surgically, not because he’s a gifted prompter, but because he understands the mathematics deeply enough to know exactly what to ask for and where to steer. Goedecke connects this to his own experience programming with AI: if you have a good theory of your codebase, you can push the LLM far harder than someone who doesn’t, asking questions like “but don’t we already do X?” or “can we express this problem in these familiar terms?” The practical implication is counterintuitive: as models get stronger, human expertise becomes more valuable, not less. The bottleneck shifts from what the model can produce to what the human can articulate — and only a domain expert can communicate the shape of a good solution. If you have no domain knowledge, you can at least get something from an LLM, and that’s not bad. But if you have expertise, you can wring far more value out of the same model by steering it hard in the direction you want. ...

Shreya Shankar (UC Berkeley PhD) presents DAB — the Data Agent Benchmark (“Can AI agents answer your data questions?”), from her PhD work at Berkeley. ~27 minutes on Hamel Husain’s channel. Why data agents matter Huge real use case: AI answering business questions — much office work is this Enterprises struggle to use Claude Code / Codex off-the-shelf for BI tasks, so they build their own data agents: Uber’s Query GPT (1.2M queries/month at launch), OpenAI’s in-house agent, Databricks, Snowflake Existing benchmarks fall short: Text-to-SQL — assumes clean data in one Postgres/Snowflake; real enterprises have fragmented data; SQL alone isn’t enough (need domain knowledge, reasoning over outputs) Table QA — context table + question; doesn’t scale to enterprise data volume The formative study — 4 real-world challenges Interviews with enterprises + Hasura (PromptQL) surfaced four properties missing from existing benchmarks: ...

Joe Barrow (ex-Amazon/Adobe, ML lead at Pattern Data, now Adobe Research’s Document Intelligence Lab) on choosing an OCR model for AI document processing. 24 minutes on Hamel Husain’s channel. Why OCR matters Your app sits downstream of OCR quality — garbage in, garbage out, no matter what the LLM does after It’s not solved — Anthropic shipped bad PDF handling for a year because it was pulling text, not doing OCR; users noticed OCR is sticky — once you build on a vendor, swapping models is painful (Pattern learned this the hard way) Documents are evil — multi-column layouts, rotated scans, no reading order; TeX-compiled PDFs have no spaces (glyph glue), so naive text extraction gives you one run of characters The decision grid: two axes Text blocks vs. document structure Text blocks: word/line bounding boxes → grounding, evidence highlighting, cheapest Structure: headings, reading order, grouped paragraphs, tables, figure alt text, chart de-rendering → much better LLM input (LLMs are trained on markdown-like structure; raw line runs look like garbage to them) API vs. self-host API: ease of use, vendor support (startups retrain on your bad docs), minimal time — right for ~95% of teams Self-host: control throughput/concurrency (APIs cap concurrent docs — a real bottleneck), stable weights, domain fine-tuning, no lock-in, cheaper at bulk — but only if your time ≈ $0 or you run huge batches The four quadrants Big cloud APIs (AWS Textract, Google Cloud Vision, Azure) — $0.60–1.50 / 1k pages; word+line boxes only; tables/forms a la carte at $10–15 / 1k Document startups (Reducto, Data Lab, Extend, LlamaIndex) — $5–20 / 1k pages, “fast” vs “accurate” tiers; structure included (markdown/HTML, tables, figure boxes) Open pipelines (PaddleOCR, Nemo Tron, Tesseract) — 10–100M params, nearly free, edge-deployable (PaddleOCR runs on phones/e-ink); text lines only, post-process with layout models Open VLMs (LightOn OCR 2, GLM OCR, GOT-OCR, Chandra/Surya) — 600M–8B params, native document structure, ~$0.20–0.30 / 1k pages on a saturated H100; hallucination risk exists but clouds hallucinate on crusty scans too How to actually choose Ignore benchmarks (OmniDocBench, CR Bench) — they’re not run on your data Build a 50–100 page sample of your own representative PDFs Run a few candidates, diff the returned text (catches junk-on-handwriting fast), visualize the boxes ~a day of effort total — then pick Watch the license Chandra/Surya (Data Lab): free only if org < $2M revenue AND not competing with Data Lab LightOn OCR: Apache. GLM OCR: MIT (but relies on PaddlePaddle’s Doc Layout model — Apache — both apply) Self-hosting, for the ~5% who should Inference engines: VL (default, OpenAI-style client) or SGLang; infra: Modal (request-queue scaling beats SageMaker), BaseTen, or big cloud for one-off batches 1B-param models (LightOn, GLM) on H100 → ~10k pages/hr, 20–30¢ / 1k pages; 4×3090 ≈ one H100 → 3–4 pages/sec His 7M-page local-laws dataset: ran over a weekend at ~30¢ / 1k all-in “You can process 1,000 pages per second, but it doesn’t matter if they’re all wrong — then your entire app’s output is going to be garbage.” ...

Jeff Su’s counter to the default “jump in, pick a template, start prompting” tutorials — that path gives you generic output and burns tokens fixing unusable slides. His fix: three files prepared ahead of time, demonstrated with the actual deck he used for a paid workshop. ...

Futurepedia’s full-platform guide to Claude Design after its big upgrade — the host skipped covering it at launch because usage limits made it barely usable; that’s fixed (usage now bundles into your existing Claude credits). The overview: 15+ template types (mobile apps, slides, documents, wireframes, animations, UI mockups, resumes, 3D objects, HTML email, flyers), and the design-system workflow that stops output from looking like generic AI slop. ...

Shreya Shankar (Stanford CS professor, co-creator of the AI evals course with Hamel) kicks off the 12-part AI product engineering series. 27 minutes on Hamel Husain’s channel. Why this matters Output quality is the biggest barrier to productionizing agents (LangSmith annual report) — and figuring out how to evaluate models is genuinely hard Vendors (LangChain, Braintrust, Arize) are selling end-to-end automated eval tools: point an LLM at your traces, it finds and fixes your bugs The catch is epistemic: what “good” means lives in your head, not in the traces — if a tool could fully fix your product, it could fix everyone’s, and there’d be nothing left to differentiate yours AI’s real job: help you express and apply your judgment faster, not replace it The eval lifecycle (analyze → measure → improve) Error analysis — the hardest step: take traces and find failure modes. No perfect definition of “mistake” (you can’t define slop, but you know it when you see it) Measure — how prevalent is each failure mode? Pareto applies: ~80% of issues come from ~20% of failure modes — prioritize those Improve — fix the product: prompt instructions, model switch, fine-tuning. Iterate forever AI is weak at the front (taste-specific error analysis) and strong at the back (measurement, prompt optimization, hill-climbing). ...