Before joining the team I started developing a comprehensible input curation engine for my own language learning purposes built on Antfly. I'm indexing Anki study decks to track my approximate passive vocabulary in Spanish, indexing public domain reading material for content, and using hybrid search/RRF to surface content that best fits my current level at any given moment. I'm also playing around with using Antfly inference to generate limited rewrites of difficult passages, in order to bring the comprehension into a range that fits my level.
It's a fun use case that seemed to sit nicely at an intersection of what antfly does well. I also think the concept generalizes nicely to broader user-adapted learning/study use cases that don't involve shipping a boat load of behavioral data to a cloud/model provider.
So far have just implemented this for reading material but could imagine extending to some cool areas! (video + audio being obvious next targets)
I've actually been using this to build a local file search agent. I started building it on the Go version of Antfly, but the new Zig runtime is a huge improvement (better resource utilization, reliability, recovery, ...)
Anyone who has used Spotlight search on macOS knows that (1) it can be an absolute resource hog, and (2) it's relatively useless (even with Siri stuff they added in macOS 27). So I was eager to take a stab at a native app that did both better and kept everything on-device (no external inference providers), and building it on Antfly meant I could run it all from one engine (way simpler to coordinate than a whole RAG pipeline).
[Disclaimer: I work at Antfly. The local search app is in preview now at searchaf.com. We plan on open-sourcing it soon (probably with its own Show HN post), as a handy reference architecture.]
I know I should be saying congrats on the new engine, but selfishly I want to hear more about how you did it.
So, the simulator only works if it knows what "correct" looks like and what kinds of failures to throw at the code, right? Who decided those two things? Was it the same agent that wrote the code? Were those human-written, or did they fall out of the formal specs?
You had three things that could each say "this is right", the end-to-end tests, the formal model, and how the old Go version behaved. When they disagreed, which one did you trust? Did the test ever turn out to be the thing that was wrong?
When the simulator caught something before release, was it usually the code that was wrong, or the definition of correct?
Feels like there's some really useful insights about best practices for coding with agents. I wonder if the Bun team used a similar approach if they still would have switched.
We definitely were combining the rewrite with the opportunity to lay foundation for a more performant architecture, for instance index management and indexing autosharding could be resourced together in the new world with slightly different semantics in the apis. So in general if the traces disagree, we can count on the new version being correct (unless the spec was covered by a TLA spec)!
At the moment the reverse is true though, the simulator and what we've captured as ground truth for the desired design has been refined enough in tests and specs that the code is often the one implicated, and most of the bugs have been in code related to caching correctness and are only exposed through soak testing.
In opposition to Anthropic/Bun, we mostly used a hands-on approach to the rewrite and took the opportunity to capture the original design of Antfly into specs and any missing tests one subsystem at a time so we didn't strive to be as hands-off as "let Claude hill-climb on the tests". Especially since the system as a whole is far more dynamic and depends more on scalability, distributed systems stuff than Bun required!
Thought it is interesting to juxtapose to the Bun rewrite from Anthropic and wanted to talk about why we went the other way! Would love to talk about our process or the technology!
DuckDB is a good one, we're working on that especially for the serverless/lakehouse stuff we've got planned for the next release! I believe we originally had qdrant in our benchmarks but ran into an explosion of testing requirements for each provider and different licensing checks for each but I can drum up those numbers!
Yeah open question what "perfect" search would even be, like would that just end up being indistinguishable from a kind of magical omniscience? And then there's "can I literally just find that one freaking slideshow from a while ago with that one client... or is it in Google Drive...?" And I really don't want the solution to be that we just plug everything into Claude
I think of perfect from two perspectives, one being "finding things I wanted to find", the other being "findings things I didn't know I wanted to find". I think Claude is great if the data isn't proprietary, secret (an all open-source project) but for dealing with Tax documents on my local machine I would hope that a search for my W2 would also find my 1099 I had forgotten I had, it'd be nice if I didn't have to allow the big AIs into everything to do that.
It can't be hosted as a cloud service correct (see ValKey by Google, OpenSearch by Amazon), there's a disclaimer on the GitHub about how and why as well.
(Disclosure: I work at Antfly, joined recently)
Before joining the team I started developing a comprehensible input curation engine for my own language learning purposes built on Antfly. I'm indexing Anki study decks to track my approximate passive vocabulary in Spanish, indexing public domain reading material for content, and using hybrid search/RRF to surface content that best fits my current level at any given moment. I'm also playing around with using Antfly inference to generate limited rewrites of difficult passages, in order to bring the comprehension into a range that fits my level.
It's a fun use case that seemed to sit nicely at an intersection of what antfly does well. I also think the concept generalizes nicely to broader user-adapted learning/study use cases that don't involve shipping a boat load of behavioral data to a cloud/model provider.
So far have just implemented this for reading material but could imagine extending to some cool areas! (video + audio being obvious next targets)
I've actually been using this to build a local file search agent. I started building it on the Go version of Antfly, but the new Zig runtime is a huge improvement (better resource utilization, reliability, recovery, ...)
Anyone who has used Spotlight search on macOS knows that (1) it can be an absolute resource hog, and (2) it's relatively useless (even with Siri stuff they added in macOS 27). So I was eager to take a stab at a native app that did both better and kept everything on-device (no external inference providers), and building it on Antfly meant I could run it all from one engine (way simpler to coordinate than a whole RAG pipeline).
[Disclaimer: I work at Antfly. The local search app is in preview now at searchaf.com. We plan on open-sourcing it soon (probably with its own Show HN post), as a handy reference architecture.]
> it's relatively useless (even with Siri stuff they added in macOS 27)
Would Antfly do better with the tasks listed at https://pogueman.substack.com/p/125-tests-of-the-new-ai-siri?
I know I should be saying congrats on the new engine, but selfishly I want to hear more about how you did it.
So, the simulator only works if it knows what "correct" looks like and what kinds of failures to throw at the code, right? Who decided those two things? Was it the same agent that wrote the code? Were those human-written, or did they fall out of the formal specs?
You had three things that could each say "this is right", the end-to-end tests, the formal model, and how the old Go version behaved. When they disagreed, which one did you trust? Did the test ever turn out to be the thing that was wrong?
When the simulator caught something before release, was it usually the code that was wrong, or the definition of correct?
Feels like there's some really useful insights about best practices for coding with agents. I wonder if the Bun team used a similar approach if they still would have switched.
We definitely were combining the rewrite with the opportunity to lay foundation for a more performant architecture, for instance index management and indexing autosharding could be resourced together in the new world with slightly different semantics in the apis. So in general if the traces disagree, we can count on the new version being correct (unless the spec was covered by a TLA spec)!
At the moment the reverse is true though, the simulator and what we've captured as ground truth for the desired design has been refined enough in tests and specs that the code is often the one implicated, and most of the bugs have been in code related to caching correctness and are only exposed through soak testing.
In opposition to Anthropic/Bun, we mostly used a hands-on approach to the rewrite and took the opportunity to capture the original design of Antfly into specs and any missing tests one subsystem at a time so we didn't strive to be as hands-off as "let Claude hill-climb on the tests". Especially since the system as a whole is far more dynamic and depends more on scalability, distributed systems stuff than Bun required!
We rewrote Antfly, which I introduced to the world a little bit back https://news.ycombinator.com/item?id=47414291, from Go to Zig.
Thought it is interesting to juxtapose to the Bun rewrite from Anthropic and wanted to talk about why we went the other way! Would love to talk about our process or the technology!
Benchmarks against are linked in the article but here they are again for posterity https://antfly.io/releases/v0.2
Could you add qdrant and duckdb to the benchmarks?
DuckDB is a good one, we're working on that especially for the serverless/lakehouse stuff we've got planned for the next release! I believe we originally had qdrant in our benchmarks but ran into an explosion of testing requirements for each provider and different licensing checks for each but I can drum up those numbers!
Yeah open question what "perfect" search would even be, like would that just end up being indistinguishable from a kind of magical omniscience? And then there's "can I literally just find that one freaking slideshow from a while ago with that one client... or is it in Google Drive...?" And I really don't want the solution to be that we just plug everything into Claude
I think of perfect from two perspectives, one being "finding things I wanted to find", the other being "findings things I didn't know I wanted to find". I think Claude is great if the data isn't proprietary, secret (an all open-source project) but for dealing with Tax documents on my local machine I would hope that a search for my W2 would also find my 1099 I had forgotten I had, it'd be nice if I didn't have to allow the big AIs into everything to do that.
Caution: antfly is not open licensed. Use it at your own risk.
It can't be hosted as a cloud service correct (see ValKey by Google, OpenSearch by Amazon), there's a disclaimer on the GitHub about how and why as well.