Posted by david927 3 days ago
Ask HN: What are you working on? (May 2026)
and for fun, I am building yet another programming language!
595 days and counting.
ᕙ(⇀‸↼‶)ᕗ
With that being said the MCP essentially will allow you to pull in directly the design specs from the top hundred (hopefully one day thousand) apps and websites. You will be able to modify them of course yourself but it'll at least enable your agent to have a grasp of what this UI looks like so you can tinker with it for your own color scheme or style from there
First up, the "AskHN for help project in progress": I'm working on some pages for my websites and want to capture + embed some interactive gaussian splats. I haven't yet found a good, embedded-able option that doesn't assume a huge dynamic website instead of my simple Hugo based static site. Any good options?
Otherwise,
I just got a vintage horn-speaker. The actual Atwater Kent driver was long since dead, but I ordered a compression driver to feed it after testing it with a talkbox and finding it sounds amazingly honky!
I have a piano's soundboard and 24 solenoids, all the drivers, etc I need to wire up to make a self playing piano (ish, I mean, it won't be hitting hammers - directly solenoid to string)
I got tired of Alexa's slow degradation into a central advertising point and weird LLM-y-ness, so just got some Home Assistant Voice Preview Editions to replace it. Performance is so far worse, so I'll be doing some tuning on that. It also means, unfortunately, replacing a lot of my lights/switches and moving to Zigbee. Total cost, with the two voice/speaker boxes + lights + switches + Zigbee hub I think I'll be about $300 deep. Not too bad.
I have a Dactyl Manuform mechanical keyboard that's 3D printed, has the keys put in, but needs soldered up, hopefully able to knock that out soon too.
Old eleksmaker pen plotter / laser engraver sitting around had it's controller die a while ago, finally got a new one, but will have to actually learn how to setup GRBL and find some open source software for driving - Which, sounds less than fun. Last time I tried, I found all the software to be expensive, hard to use, and generally frustrating.
On top of all of that,
* I have a Hurdy Gurdy sitting at about 3/4 finished, shouldn't need more than another 8 or so hours of work to get playable.
* I want to make some Nuclear Instrumentation Module inspired modules for VCV rack
* I have an AudioMoth on the way, I'm looking forward to learning how to setup so I can learn about bats in my area!
* I'm still about 75% done switching back to linux, now that I feel it's finally ready to be used for music stuff since the transition to Pipewire seems over with and It's no longer a total mess of ALSA+JACK+Pulse+PipeWire. That transition hell mad me switch back to windows for few years, and it's nice to be back
Also, since the last thread I've managed to fully rebuild my studio setup, setting up multiple 3-tier stands for synths + the Wall-o-pedals. It came out really well! Was nice to brush up on at least basic wood working skills for it too. During that project I also discovered 3M dual lock is magic and will be over-using it on everything from now on.
- 'agent' as cognitive state, ie, what to think about
- 'workflow' as 'what to think about
- 'session' as immutable agent history
- 'timers' as a way to kick off an agent on a schedule (with or without a workflow attached
I've been working on this since just before OpenClaw dropped at the end of January. Currently it weighs in at around 20k lines of code. There is still a significant amount of work to be done on polish, but the core appears to be functional, and almost to the point where I can replace opencode as my daily driver (I'm very much looking forward to this).
From [1]:
---
I've been working on a framework since the end of January or so. I'm on my 7th draft. As I've gone along, each draft gets markedly smaller. The overlaps between what I'm building and openclaw are significant, but I've realized the elements that make up the system are distinct, small, and modular (by design). There are only a few primitives:
1. session history
1a. context map + rendered context map (think of a drive partitioning scheme, but for context -- you can specify what goes into each block of context and this gets built before being sent out for inference).
2. agent definition / runtime
3. workflow definition / runtime
4. workflow history
5. runtime history (for all the stuff session and workflow history fail to capture because they are at a lower level in the stack)
That's it. Everything else builds on top of these primitives, including
- memory (a new context block that you add to a context map)
- tool usage (which is a set of hooks on inference return and can optionally send the output straight back for inference -- this is a special case inside the inference loop and so just lives there)
- anything to do with agent operating environment (this is an extension of workflows)
- anything to do with governance/provenance/security (this is an extension of either workflows and/or agent operating environment... I haven't nailed this down yet).
I suppose I should say something about how agents and workflows work together. I've broken up 'what to do' and 'how to think' into the two primitives of 'workflow' and 'agent' respectively. An agent's context map will have a section for system prompt and cognitive prompt, and an agent can 'bind' to a workflow. When bound, the agent has an additional field in their context map that spells out the workflow state the agent is in, the available tools, and state exit criteria. Ideally an agent can bind/unbind from a workflow at will, which means long-running workflows are durable beyond just agent activity. There's some nuance here in how session history from a workflow is stored, and I haven't figured that out yet.
Generally, the idea of a workflow allows you to do things like scheduled tasks, user UI, connectors to a variety of comms interfaces, tasks requiring specific outputs, etc. The primitive lays the foundation for a huge chunk of functionality that openclaw and others expose.
It's been fun reasoning through this, and I'll admit that I've had an awful lot of FOMO in the mean time, as I watch so many other harnesses come online. The majority of them look polished, and are well marketed (as far as AI hype marketing goes). But I've managed to stay the course so far.
I hope you find your ideal fit. These tools have the potential to be very powerful if we can manage to build them well enough.
---
I have no public sources yet (will come at some point) but ill try to break it down into some simple points. After all: this is a research project.
Project: DeepThought
So instead of going for the path to take bigger and bigger models to solve more complex questions, i going another direction. My idea is to use LLM's in a way like an "inner monologue" to replicate a thought chain. Basically create thinking steps that can be dynamically chained.
Additionally, the project contains a 3 layer memory system which is parted into:
1. Frontbrain (this data composes the context for inference, its a set of "hot nodes" which have a temprature that per turn of conversation will cool down a bit, while if they are used in a "thinking process" get warmed up a big again. The idea is to have the context for the inference to only get the currently relevant information, while dropping of things that lost relevance. This should prevent context overflow
2. STM : Basically a session memory. This will keep all information from the current session even if they got to cold and dropped out of Frontbrain
3. LTS : LTS is always query'able for the thought process to retrieve information/structures, but only at the sessions end information is propagated from the STM to LTS. This makes identification of "unique" entities alot easier and has some other advantages.
So when you type something into the DeepThought engine, it will extract all information from your input and convert it into a kinda 2 type structure 1. A bitemporal hypergraph composed of Entities and Hyperatoms. While entities i think are kinda easy to grasp, hyperatoms can either represent "properties" (in form of facts) or relations to other entities. This allows to create a graph structure typed information network containing the relevant information
2. Frame summaries. Since only having a structured graph as just described looses a lot of processual/logical information which are relevant especially in more complex contexts, i also create basically short summary texts that are linked to entities.
This structures allow me to use dynamic graph traversal for searching for data, while also retrieving the related Frame summaries that are a more native variant for an LLM to understand logics and relations.
This is a very very superifical explaination because to go into detail would take quite prolly multiplage pages of info.
Important: Im running this on a local 5090 and it is NOT friendly in terms of amount of inferences (which is fine for me). I try to mimic a thought process not build a fast shipping product. Quality > quantity. If you would run DeepThought on any online inference provider your broke in 1 day.
So, rn i focus on the ingestion and retrieval logics to make storing and retrieving as good as possible with my hw options.
While the ingestions already involves multiple steps in which the "llm" basically works as judge to decide where to traverse in the graph, where to go into recursion and similar, this will become very relevant as soon ill start implementing "task execution" as capability.
If i solved those the next point is to reduce everything that i need in terms of thinking steps in what i would call "thinking primitives". The idea with those is, that i dont want a hardcoded thinking process, but it rather also want to have the thinking process in form of a graph structure. This would allow me to compose the process in form of data in the hyepergraph, which would in return allow me to enable the system to refactor/enhance its own thought processes.
So ye thats what im working on rn, very early concept/alpha phase.
The original developer has left our organization so I’ve been tasked with general assessment and winding it down to enter maintenance mode. It’s still alive and well, has a very passionate and appreciative user base, but we want to ensure it doesn’t demand too much attention moving forward while we focus on other things. It has pretty noisy error reporting.
Reliability and fault tolerance are some of my favourite things to work on in software so it has been a lot of fun so far. It has also been an incredible opportunity to practice using LLMs for specs, planning, verification, and research. I don’t actually need to output much code to get this thing into a stable state in which it can coast along; the bulk of the work is time spent understanding the app, the infrastructure, its existing faults, poring through traces and logs, going over query plans, and so on. LLMs are great assistants for this work and I’m having a ton of fun having so many opportunities to figure out what works and what doesn’t.
The outcome has been awesome. The performance is steadily climbing (especially in the database), and most common errors when I started are either gone or much better understood with plans to address them. I’ve almost got it set up so if someone needs to take it over in the future, it should be pretty easy to toss them the keys and trust that they can deploy and maintain it easily from the docs and systems I’ve created.
Despite spending a lot of my career on the front end, the hardest part of this project has been navigating that. Aiming to improve an application with minimal intervention is exceedingly difficult in the browser, or so I’ve been finding. I can get incredible performance gains out of Postgres without changing the interface between lambda and rds in the slightest, but meaningful improvements to the react application seem virtually impossible without substantial refactoring.
I understand the key factors in getting better performance out of react apps and I see plenty of opportunities, but they all involve large diffs that are risky and time-consuming, even with a model like Opus handy to churn through boring and large change sets. It’s such a fragile and flaky environment.
Even so, I’m loving it. Making software better is so gratifying. Doing it without reinventing the world is such a fun challenge, too. It really puts your brain to work. It would be so easy to go in and start flipping tables and throwing code in the garbage, but that’s too easy and too risky. Taking it slow, absorbing as much information as you can, truly understanding how features work, and planning surgical changes with significant pay off is safer and just feels awesome when it works.
I’ll be sad when this one is finished. It’s almost there. Next up is a remote temperature controller for 40 saltwater experiment tanks with a temperature profile planning interface and a monitoring interface for the lab. That will be awesome too. It has been a good couple of months for work.