[dead]
Ask HN: What Are You Working On? (March 2026)
451–460 of 1001 posts
Re: Ask HN: What Are You Working On? (March 2026)
#452I finally decided to try and make a note taking tool I've been wanting to use. https://chrononotes.com/ As many here, I've found that a single text file is all that I really need, but found that it makes it difficult to keep track of a variety of things. I was also trying to use the file as a simple project tracker, adding some tags like [BUG-N], and updating them by hand. Eventually, it became difficult to track the…
This looks great if combined with versioning system. As part of git repor for example.
But, for general journaling, I would not trust something that does not leverage the strengths of a filesystem.
Re: Ask HN: What Are You Working On? (March 2026)
#453I'm working on an IoT networked, time sync'd "Smart Dealer Poker Button" - replacing the plastic thing that gets passed around from the current dealer to the next dealer with a IoT display that informs players what level the blinds are etc etc.
Provisional patents went in recently so don't mind broadcasting to a wider audience beyond my poor, unknowing, testers
You can see it working here: https://www.youtube.com/watch?v=G5Xup3kB1D0 and I literally put up a holding page for some media related surges (as it's all self hosted etc and I didn't want to mix my functional stuff with my spikey stuff) here ( name to be worked on, but "NUTS" is the current one) : https://buttonsqueeze.com
Re: Ask HN: What Are You Working On? (March 2026)
#454I am creating AI coding framework (a set of skills and scripts, really), since it seems a lot of them don't support copilot.
I don't think what I am doing is really original, but it's shaping nicely.
I am working on:
- feature folders (one folder per feature, with changelog, issues, summaries etc)
- coworkers (cli-agents, with session management)
- agents intra-response messaging
In general the goal is forcing Claude to behave, which is quite ambitious :).
Re: Ask HN: What Are You Working On? (March 2026)
#455A fully vibe coded python 3.14 interpreter in Rust: https://blueblazin.github.io/pyrs Now at 350k lines. Native and wasm binaries (you can try the limited wasm version online). Currently adding a full CPython test suite benchmark. Just for fun, not trying to replace CPython here. Mainly to test the limits of current coding agents.
And how is it going, in terms of finding those limit? It would be very interesting to hear about areas where the actual experience turned out to be wildly different from your expectations, in either direction.
Re: Ask HN: What Are You Working On? (March 2026)
#456Managed BYOK stateless agent orchestrator called BeeZee: https://beezyai.net/. Basically Claude Cowork / a coding agent on the web but provider agnostic, you own the data and you can connect several nodes to it. Instead of installing an agent for all your machines you have one master agentic server and executor nodes. The server is stateless the data lives on the nodes and in a managed database. I use Supabase and Google KMS so my auth keys are encrypted. Uses Pi agent under the hood. This enables me to code from my phone without a dedicated SSH terminal and without the need to babysit the agent. I describe the feature, off it goes, I close my phone and in 10 mins the results are there. Also using it to support my wife with white collar stuff like Excel analysis, translation, etc. It's a bit buggy but getting better.
Re: Ask HN: What Are You Working On? (March 2026)
#457A lightweight framework on top of Temporal for building reliable, stateful AI agents on top of temporal.
Think OpenClaw, but durable, with long-term state, and enterprise-ready. We've been using it internally to build agents for a while now and have decided to open-source it.
Re: Ask HN: What Are You Working On? (March 2026)
#458[dead]
Re: Ask HN: What Are You Working On? (March 2026)
#459Rewriting the backend Bitwise Cloud, my semantic search for embedded systems docs Claude Code plugin from Python to Go.
The problem was the ML dependencies. The backend uses BGE-small-en-v1.5 for embeddings and FAISS for vector search. Both are C++/Python. Using them from Go means CGO, which means a C toolchain in your build, platform-specific binaries, and the end of go get && go build.
So I wrote both from scratch in pure Go.
goformer (https://www.mikeayles.com/blog/goformer/) loads HuggingFace safetensors directly and runs BERT inference. No ONNX export step, no Python in the build pipeline. It produces embeddings that match the Python reference to cosine similarity > 0.9999. It's 10-50x slower than ONNX Runtime, but for my workload (embed one short query at search time, batch ingest at deploy time) 154ms per embedding is noise.
goformersearch (https://www.mikeayles.com/blog/goformersearch/) is the vector index. Brute-force and HNSW, same interface, swap with one line. I couldn't justify pulling in FAISS for the index sizes I'm dealing with (10k-50k vectors), and the pure Go HNSW searches in under 0.5ms at 50k vectors. Had to settle for HNSW over FAISS's IVF-PQ, but at this scale the recall tradeoff is fine.
The interesting bit was finding the crossover point where HNSW beats brute-force. At 384 dimensions it's around 2,400 vectors. Below that, just scan everything, the graph overhead isn't worth it. I wrote it up with benchmarks against FAISS for reference.
Together they're a zero-dependency semantic search stack. go get both libraries, download a model from HuggingFace, and you have embedding generation + vector search in a single static binary. No Python, no Docker, no CGO.
Is it better than ONNX/FAISS? Heck no. I just did it because I wanted to try out Go.
goformer: https://github.com/MichaelAyles/goformer
goformersearch: https://github.com/MichaelAyles/goformersearch
Re: Ask HN: What Are You Working On? (March 2026)
#460Building grith — OS-level syscall interception for AI coding agents. The problem: every agent (Cline, Aider, Codex, Claude Code) has unrestricted access to your filesystem, shell, and network. When they process untrusted content — a cloned repo, a dependency README — they’re prompt injection vectors with full machine access. No existing tool evaluates what the agent actually does at the syscall level. grith wraps any…
Each syscall taking 15ms on top of the normal considered costly time taken for context switching to the kernel seems excessivly slow, no?