Ask HN: What are you working on? (July 2025)

Me and 2 cofounders are in searching for our next B2B startup idea to implement. We come from different backgrounds (im the tech guy). We are in the process of market research for prospective ideas.

Today (Sunday) I've spent the day studying Analogical Reasoning. Specifically reading chapters from The Analogical Mind by Gentner, Holyoak, and Kokinov (eds), and Similarity and Analogical Reasoning by Vosniadou and Ortony (eds).

Beyond that, I've spent most of the weekend working on some "test harness" code for doing AI research. You all may have seen me mention XMPP a few times over the last year or so and if so, you have have rightly wondered "What does XMPP have to do with anything?"

Good question. The short answer is "nothing, in and of itself."

That is, there's nothing in particular about XMPP that has anything to do with AI. I'm just using XMPP as a convenient interface to interact with my AI experiments. The thing is, most of this code was written in very much an "exploratory programming" style (eg, "vibe coding before vibe coding was a thing and done without an LLM"). As such, the architecture and structure of the code is kinda crap and it's hard to extend, reuse, modify, etc. There's too much "XMPP stuff" tightly coupled to my "Blackboard" system[1] and nothing was written to use dependency injection and so on.

Soooooo... I've spent a bunch of time over the weekend re-working that stuff to make my test harness much more useful. Now, all the "XMPP stuff" is contained to a single deployable unit, and the Blackboard stuff is likewise properly designed to allow making all the components Spring managed beans and wired together in a Spring Boot application. And that in turn exposes it's interface as a simple REST API. One thing I'm debating now is if I want to try and coerce this into fitting the OpenAI API model, and then adopt the OpenAI API for my backends[2]. Still debating with myself on that point.

Anyway, with this stuff done, it will be easy to switch out the AI backend components, run parallel tests, and do other nifty things. One thing I'll probably do is integrate Apache Camel into the XMPP receiver component to support complex message routing logic where desired.

I also finally created a Dockerized build for all of this stuff and a docker compose file, so now I can just run "docker compose up" and have a running system in a few seconds. And since everything is built as a Docker image now, if I want to move this to K8S or something in the future that becomes less of a slog.

All in all, I have gotten quite a bit done the last couple of days. I attribute a lot of this to the success of my eye procedure on Thursday. Now that I can see again, and am not experiencing near constant severe levels of eye strain and fatigue, it's a LOT easier to get stuff done!

[1]: https://en.wikipedia.org/wiki/Blackboard_system

[2]: As an aside, I say "coerce" because what I'm doing is not fundamentally based on LLM's or GenAI in general. Most of this work is either purely symbolic AI, or neuro-symbolic hybrid stuff at present. That said, I do allow for the possibility of using an LLM in places, especially for the "language" part. That is, if my system does a bunch of computation and creates an "answer" as a bunch of RDF triples or something, I can then take that and feed it to an LLM and say "translate this into conventional English prose" or whatever. I'm not an absolutist about any particular approach.

A Pomodoro timer to improve my skills but primarily as an excuse to get better at various AI coding tools when they pop up.

A website down-time detector because I think I can make money off it and learn a few things so I can later launch a grown-up SaaS.

A replacement for MS Notepad but with Markdown support. (I know Notepad sort of added this but it isn't great.) It's the tool I want to have when I say, "I like the way I can edit things in Notion and Obsidian but 95% of the functionality of those apps feel like bloat for my use case".

I'm working on hessra.net, a token-based authorization system for machines and built using biscuits. The idea is that any service/machine/IoT device can authenticate to the service and get authorization tokens for each request based on policy. Then the tokens can be included with the request and verified without any further RTTs using the service's public key. The tokens are meant to be single-use and scoped to a single request.

Besides the simple "get token and send to a thing that uses it to authorize a request" there's a couple of things we've built/are building on top:

service-chains: for a given resource, you can configure the token so that it needs to be signed by notable components along the path of the request, and at each step along the path check that it was signed by expected components up to that point. the thinking is this could really cut down on lateral movement in a system

multi-party authorization: for a given resource, you can configure N authorization services that also need to sign the token based on their policy. the token only authorizes if all parties have signed it. this could be useful for managing capabilities of software deployed into customer environments or perhaps for b2b agents to get signoff from both b's for doing an action

Lately I’ve been heads‑down on a complete rethink of my dotfiles setup. It’s not just a `.vimrc` collection – the goal is to treat the dev environment like any other project: reproducible from scratch, automated, and designed to scale as AI becomes a bigger part of daily work.

The core of the project is a “Spilled Coffee Principle,” which basically says that if I spill coffee on my laptop, I should be back up in an afternoon. Every configuration change is codified into scripts, not a one‑off terminal command. Setup scripts create directories, handle symlinks, document dependencies and generally remove the “Brent the bottleneck hero” problem.

Beyond that, the repo lives inside a P.P.V system (Pillars, Pipelines, Vaults) where dotfiles are one of the pillars. This structure separates foundational configs from automation pipelines and secure vaults. It forces me to think at the system level: how do all of my tools fit together, where do secrets live, and how can I onboard a new machine (or person) with a single `git clone && ./setup.sh`?

What’s really interesting is the mindset shift this has caused. I’ve been experimenting with what I call the OSE (“Outside and Slightly Elevated”) principle: moving from micro‑level, line‑by‑line coding to a macro‑level role where you orchestrate AI agents. At the micro level you’re navigating files in an editor and debugging sequentially; at the macro level you’re using tmux + git worktrees + AI coding assistants to run multiple tasks in parallel. Instead of `1 developer × 1 task = linear productivity`, you get `1 developer × N tasks × parallel execution`, which has obvious 100×–1000× potential. This OSE approach forces me to design workflows, delegate implementation to agents, and focus on the “why” and “what” instead of the “how”.

The result is that my dotfiles aren’t just about aliases anymore; they’re a platform that bootstraps AI‑assisted development, enforces good practices, and keeps me thinking about the bigger picture rather than getting lost tweaking my prompt or editor colours. I’d love to hear how others are approaching the macro vs. micro balance in their own setups.