frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Willingness to look stupid

https://sharif.io/looking-stupid
289•Samin100•3d ago•107 comments

Executing programs inside transformers with exponentially faster inference

https://www.percepta.ai/blog/can-llms-be-computers
72•u1hcw9nx•23h ago•9 comments

Bucketsquatting Is (Finally) Dead

https://onecloudplease.com/blog/bucketsquatting-is-finally-dead
6•boyter•27m ago•0 comments

Malus – Clean Room as a Service

https://malus.sh
1244•microflash•19h ago•448 comments

Vite 8.0 Is Out

https://vite.dev/blog/announcing-vite8
241•kothariji•4h ago•56 comments

“This is not the computer for you”

https://samhenri.gold/blog/20260312-this-is-not-the-computer-for-you/
398•MBCook•7h ago•159 comments

Prefix sums at gigabytes per second with ARM NEON

https://lemire.me/blog/2026/03/08/prefix-sums-at-tens-of-gigabytes-per-second-with-arm-neon/
35•mfiguiere•4d ago•2 comments

Hyperlinks in Terminal Emulators

https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
50•nvahalik•5h ago•31 comments

Bubble Sorted Amen Break

https://parametricavocado.itch.io/amen-sorting
326•eieio•15h ago•99 comments

ATMs didn’t kill bank teller jobs, but the iPhone did

https://davidoks.blog/p/why-the-atm-didnt-kill-bank-teller
406•colinprince•18h ago•435 comments

Shall I implement it? No

https://gist.github.com/bretonium/291f4388e2de89a43b25c135b44e41f0
1240•breton•11h ago•462 comments

Reversing memory loss via gut-brain communication

https://med.stanford.edu/news/all-news/2026/03/gut-brain-cognitive-decline.html
303•mustaphah•16h ago•119 comments

Understanding the Go Runtime: The Scheduler

https://internals-for-interns.com/posts/go-runtime-scheduler/
105•valyala•3d ago•9 comments

IMG_0416 (2024)

https://ben-mini.com/2024/img-0416
81•TigerUniversity•3d ago•15 comments

The Met releases high-def 3D scans of 140 famous art objects

https://www.openculture.com/2026/03/the-met-releases-high-definition-3d-scans-of-140-famous-art-o...
279•coloneltcb•17h ago•54 comments

Document poisoning in RAG systems: How attackers corrupt AI's sources

https://aminrj.com/posts/rag-document-poisoning/
116•aminerj•19h ago•45 comments

Celebrating Interesting Flickr Technologies

https://medium.com/@brightcarvings/celebrating-flickr-technology-3c93c8ddecc2
32•steerpike•1d ago•6 comments

Worldwide Sidewalk Joy: Adding whimsy to neighborhoods

https://worldwidesidewalkjoy.com
12•NaOH•3d ago•3 comments

US private credit defaults hit record 9.2% in 2025, Fitch says

https://www.marketscreener.com/news/us-private-credit-defaults-hit-record-9-2-in-2025-fitch-says-...
352•JumpCrisscross•20h ago•407 comments

Never Snooze a Future

https://jacko.io/snooze.html
8•vinhnx•4d ago•1 comments

Grief and the AI split

https://blog.lmorchard.com/2026/03/11/grief-and-the-ai-split/
139•avernet•10h ago•215 comments

Bringing Chrome to ARM64 Linux Devices

https://blog.chromium.org/2026/03/bringing-chrome-to-arm64-linux-devices.html
101•ingve•12h ago•46 comments

Innocent woman jailed after being misidentified using AI facial recognition

https://www.grandforksherald.com/news/north-dakota/ai-error-jails-innocent-grandmother-for-months...
592•rectang•12h ago•305 comments

Big data on the cheapest MacBook

https://duckdb.org/2026/03/11/big-data-on-the-cheapest-macbook
350•bcye•21h ago•278 comments

Can you instruct a robot to make a PBJ sandwich?

https://pbj.deliberateinc.com/
26•mooreds•5h ago•28 comments

WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations

https://github.com/wolfssl/wolfip
127•789c789c789c•17h ago•21 comments

Are LLM merge rates not getting better?

https://entropicthoughts.com/no-swe-bench-improvement
146•4diii•21h ago•133 comments

Ceno, browse the web without internet access

https://ceno.app/en/index.html?
3•mohsen1•2h ago•0 comments

Show HN: Axe – A 12MB binary that replaces your AI framework

https://github.com/jrswab/axe
190•jrswab•19h ago•105 comments

Launch HN: IonRouter (YC W26) – High-throughput, low-cost inference

https://ionrouter.io
62•vshah1016•14h ago•25 comments
Open in hackernews

Infinite Tool Use

https://snimu.github.io/2025/05/23/infinite-tool-use.html
83•tosh•9mo ago

Comments

anko•9mo ago
I have been thinking along these lines myself. Most of the time, if we need to calculate things, we'd use a calculator or some code. We wouldn't do it in our head, unless it's rough or small enough. But that's what we ask LLMs to do!

I believe we juggle 7 (plus or minus 2) things in our short term memory. Maybe short term memory could be a tool!

We also don't have the knowledge of the entire internet in our heads, but meanwhile we can still be more effective at strategy/reasoning/planning. Maybe a much smaller model could be used if the only thing it had to do is use tools and have a basic grasp on a language.

dijit•9mo ago
I was once told that we can only hold 7 things in our heads at once, especially smart people might manage 9; this was by a psychologist that I respect- whether its true or not I am not certain. He was using it as an argument to either condense the array of things I was thinking about into smaller decisions, or to make decisions and move on instead of letting them rot my brain.

It was good advice for me.

blixt•9mo ago
Let’s not forget that every round trip with the LLM costs latency (and extra input tokens). We now have parallel tool calls which sometimes works in some models[1]. But it’s great because now a model can say “write these 3 files then read these 2 files” before the time-to-first token latency is incurred once more (not to mention input token cost).

I think LLMs will indirectly move towards being fuzzy VMs that output tokens much like VM instructions so they can prepare multiple conditional branches of tool calling, load/unload useful subprograms, etc. It might not be expressed exactly like that, but I think given how LLMs today are very poor at reusing things in their context window, we will naturally add features that take us in this direction. Also see frameworks like CodeAct[2] etc.

[1] This can be converted to a single tool call with many arguments instead, which you’ll see providers do in their internal tools, but it’s just messier.

[2] https://machinelearning.apple.com/research/codeact

brador•9mo ago
Your only useful purpose is to assign the goal. Everything else is an uppity human getting in the way of a more efficient (and more creative) production system.
rahimnathwani•9mo ago
I'm wondering how we might apply this to the task of writing a novel.

There's an open source tool being developed that is sort of along these lines: https://github.com/raestrada/storycraftr

But:

- it expects the user to be the orchestrator, rather than running fully unattended in a loop, and

- it expects the LLM to output a whole chapter at a time, rather than doing surgical edits: https://github.com/raestrada/storycraftr/blob/b0d80204c93ff1...

(It does use a vector store to help the model get context from the rest of the book, so it doesn't assume everything is in context.)

ksilobman•9mo ago
> Give it access to a full text-editor that is controllable through special text-commands, and see many benefits

I’d like to apply what is being suggested in this post, but it doesn’t make sense to me to have to give an LLM access to a text editor just to write a novel. Isn’t there a better way?

dazzaji•9mo ago
I’m still stuck on the first sentence "An LLM should never output anything but tool calls and their arguments” because it just doesn’t make sense to me.

Tool calling is great, but LLMs are - and should be used as - more than just tool callers. I mean, some tools will have to be other LLMs doing what they’re good at, like writing a novel, summarizing, brainstorming ideas, or explaining complex topics. Tools are useful, but the stuff LLMs actually do is also useful. The basic premise that LLMs should never output anything beyond tools and arguments is leaving most of the value of LLMs on the table.

bsenftner•9mo ago
I think the blog simply does not explain well. Consider the example of a text editor, the "tool calls" are text fragments generated by the LLM then embedded into text editor tool calls that place the generated text fragment into the text editor, performing cuts, pastes, and so on.

FWIW, I've done this and it works incredibly well. It's essentially integrating the LLM into the text editor, and requests of the LLM are more like requests of the text editor directly. The mental model I use is the editor has become an AI Agent itself. I've also done with with spreadsheets, web page editors, various tools in project management software. It's an incredible perspective that works.

dazzaji•9mo ago
Got it, thanks for clarifying! So if I’m understanding you right, you’re saying that all the generative stuff the LLM does—like creating text—basically becomes part of the ‘arguments’ the original post talks about, and then that gets paired with a tool call (like inserting into a text editor, doing edits, etc.). I was focused on the tool call not the argument content aspect of the post.

And it sounds like you’ve had a lot of success with this approach in an impressive variety of application types. May I ask what tooling you usually use for this (eg custom python for each hack? MCP? some agent framework like LangGraph/ADK/etc, other?)

bsenftner•9mo ago
I noticed fairly early that the foundation LLMs have the source code to most FOSS, as well as the developer conversations, the user discussions trying to understand how to use that software, and the documentation too. The foundational models have a good amount of training data of each popular FOSS app, and by examining the code and the developer comments, and then adopting their language style, the LLM practically takes on the persona of the developer. So I spent some time understanding the internal communications of each app, and my 'tool calls' are structured JSON of the internal structures these applications use, and my own code receives these structured outputs and I just replace in the application's running memory. Not quite so blind as I describe, some of the insertion of these data structures is complicated.

In the end, each app is both what it was before, as well as can be driven by prompts. I've also specialized each to have 4 agents that are as I describe, but they each have a different representation of the app's internal data; for example, a word processor has the "content, the document" in HTML/CSS as well as raw text. When one wants to manipulate the text, requests use the HTML/CSS representation, and selections go through a slightly separate logic than a request to be applied to the entire document. When one wants to critically analyze the text, it is ASCII text, no need for the HTML/CSS at all. When one wants to use the document as a knowledge base, outside the editor, that's yet another variant that uses the editor to output a RAG ready representation.

dazzaji•9mo ago
That system would make a tidy startup, especially if tightly integrated with an open source office suite behind the scenes (LibreOffice, OpenOffice, etc) and a generative AI native UX.
dazzaji•9mo ago
* I'd call it "VibeOffice".
ayolisup•9mo ago
A naive approach could be to create an outline, then have an LLM randomly sample a section, supply the surrounding context, rewrite that part, then repeat, ideally alongside human writing. Some sort of continuous revision cycle.
yencabulator•9mo ago
The underlying problem might get solved differently with diffusion.

https://news.ycombinator.com/item?id=44057820

PeterStuer•9mo ago
In theory not being 'locked in' on the early generation track is a potential advantage of diffusion LLM's. In practice it remains to be seen wether they can truly outperform the current standard LLM with heurstics.