+1 to Incus. In fact, our meta-harness of sorts, Sail, is built using Incus. The vision was to have Sail do for coding agents roughly what Kubernetes does for containers, i.e., orchestrating and dispatching engineering work to CC/Codex etc. Our small team of engineers has found decent success with this approach.
I've been able to build an experimental version of Live, typed queries on real Postgres.
It started from a question I had: can a Java-shop get the "subscribe, and the UI updates when the data changes" experience of Firebase or InstantDB without giving up a real relational database and without using ORM.
Haven't experienced flow state in a while, since CC became my default IDE :)
I built my version of a meta harness that guides claude and codex in a code => review loop. I typically brainstorm a task and dispatch it. The actual coding and review by the LLMs is done in a sandboxed Incus container. A WIP https://github.com/standardapplied/sail
As everyone knows, in a typical Java app, data moves through multiple stations just to get out the door: JDBC, ResultSet, POJO mapping, Hibernate sessions, Jackson serialization, etc. Every station allocates memory. Every station loses type info the next one has to rediscover.
I wanted to see what happens if we strip the pipeline down to its absolute minimum. The result is an experimental library I’m calling Monolith. It uses Java FFM (Foreign Function & Memory API) to talk directly to Postgres.
The core premise: a single Java record is the source of truth. You write a record, and an annotation processor generates the Postgres schema, a binary reader, a builder, and a matching TypeScript reader at compile time. No reflection. While building it, I also added support for live queries. One can subscribe to a query, and Monolith watches the Postgres write-ahead log (WAL) to know when underlying rows change, automatically re-running the query and pushing the new result.
To be clear: this is v0.1. It is highly experimental. Postgres is still a server over a socket. This might be a terrible idea but it was a great excuse to push Java FFM.
We tend to obsess over abstractions, frameworks, and standards, which is a good thing. But we already have BDD and TDD, and now, with english as the new high-level programming language, it is easier than ever to build. Focusing on other critical problem spaces like context/memory is more useful at this point. If the whole purpose of this is token compression, I don't see myself using it.