jesol

Personally I think security is far ahead here compared to normal observability tools. I decided to work on a side-project to try and add SIEM like functionality to a clickhouse backed otel platform; by the end of it the thing I came to believe the tooling blue teams use should be used in observability generally, not just security. Incident/event management is a very powerful concept, and provides a clean framework to hang all of this information on. Then your solution for mechanically finding the neighborhood in k8s is one way to add observations to an event. Some SIEMs have started having agents recommend stuff to be added to an event, which is a nice middle-ground of having agents help but not completely control the discovery and diagnostic effort (as well as providing a clean feedback loop for training data synthesis).

That's all to say, have you considered that framing, and if so, have any opinions on why more general observability tools haven't gone that direction?

Basically I'm designing a two layer interface, the first layer speaks app UI specific language and runs playwright directly (signin, dismiss toast, go to dashboard), and then the second speaks product language ("user opens dashboard" in Gherkin would translate to signin, wait for app to load, go to dashboard; for example). The translation from product level language to app level language is the step definition files bddgen uses. I'm building up a little skills library to try and force Claude to stick to these separate levels of abstraction; then also do deduplication and cleanup after implementing new specs.

We don't really use images for acceptance testing, it's more functionality. I don't really care where the button is, just that if I click it, it does what it says it does. To that end, we already have multi-tenancy in the application (I highly recommend every app build this in, if only for testing; then you don't need to do the Postgres template1 seeding hacks), so we spin up a tenant for a test, do all the setup with the API (all the Given statements), playwright to do the validation of a feature (the When statements), and finally validation is a mix of Playwright and API (the Then statements).

Sorry if that isn't super clear; maybe I could put together a little demo repo or something if people have any interest; I'm hoping to do that after I introduce typespec and dbml (basically spec/{acceptance,api,db}).

I also think BDD is a really powerful tool for UI acceptance tests! I've now worked on adding it to two AI codebases (one engineered, another vibecoded), and so far it has been mostly positive. Having non-engineers be able to see what effects their code changes have in the UI is nice; and I find having high level API and UI tests is forcing the first layer of cleanup (standardize access to DB through models/services, and a single API SDK).

I am also really interested in standardizing the REST interface with typespec, and the database schema with DBML. I think creating these closed-loops with high-level specs is one of the best ways to make an AI project ownable by a team.

I think we need a new area of study around UI/Agent connection. It can kinda be done with tools, but I'd we need much deeper primitives to allow the UI to inform the Agent and vice-versa. Right now we've just given up, replacing the UI with an Agent message view, but I think that's just because nobody is thinking about how the two can compliment each other

I've been playing around with using a hidden markov model informed by a UI state event stream, with the end state fed into the Agent as a hint on each message turn. Then the Agent can make a tool call to add events to the HMM. This has been really interesting, but I haven't struck the right balance to make it actually feel good for the user yet

Love TUI apps, hate that there isn't a clean way to control native scrollback. It leaves you stuck between manually managing it via awkward hacks on the current visible screen, or not using it at all. I've been working on an LLM harness TUI for a little while, and this specific part has been the most frustrating (in conjunction with tmux).

I've been working on a graph database in Rust this year actually! I'd love to hear anything you can talk about wrt the query planner and/or how you decided to do cardinality estimation. I decided to go with an EAV graph which makes CE pretty complex, and it's been an interesting challenge to balance quality and speed and expressiveness in the query language

I'm building a CRDT replicated EAV graph store with reactive datalog optimized with a cascades query planner, and uses random walks during planning of the data on disk (assume NVMEs) for cardinality estimation. The idea is to provide a structured knowledge base that can quickly run queries on relatively small data (10m-100m facts) to an LLM, and teach the model to always do research within the knowledge base using powerful analytical queries wrapped in a pure functional language for formatting results (starlark in my case). Then, you would create adapters to sync data into the system, and the data instantly becomes discoverable by the LLM to help answer questions in a structured way. The LLM could also subscribe to queries and receive delta propogations as data changes to agentically react to updates.

The knowledge base is eventually consistent across computers so you could run ingestion into a knowledge base on your desktop, and just connect and replicate it to your laptop when it's online. I've been having a lot of fun learning about Cascades query planning, and it's given me an excuse to spelunk in the Data Fusion codebase (we're both writing query planners in Rust). It turns out Microsoft put together an incredible reference about this in 2024 [1], and one of the primary authors did an awesome talk about it on youtube [2], for those interested.

And yeah, it's all vibe-coded. I've gone through 8 PoCs for cardinality estimation and 3 query planners before arriving at my current design. The ability to try stuff, rip it out, try other things; has been incredible. I would have either given up or been stuck with my first or second attempt right now without an LLM to help me quickly prototype concepts

[1]: https://www.microsoft.com/en-us/research/wp-content/uploads/... [2]: https://www.youtube.com/watch?v=GQsoNdvFbuo

I don't have hard data, but I own 3 air gradients and they've been going strong for years. I don't think it's unreasonable to think they just got unlucky

Yes.

Definitely not. Repealing section 174 (or not extending it, as it were) helped pushed us into a new normal for the market. Adding it back doesn't in and of itself push the market into another new normal, we'd need a lot more. It might take the edge off though, hopefully.

I don't know anything about electronics design, but I'm really into backpacking so a high efficiency battery system with a solar panel is really interesting to me. I came across this project[1], and wanted to improve upon it for my usecase. I want to add the ability to have multiple 21700 cells in a lightweight charger, instead of a single cell with a builtin USB charger. I want to learn more electronics, but it definitely feels like a multiyear process, and it'd be nice to shortcut it for the projects I'm interested in.

1. https://www.reddit.com/r/myog/comments/1k3stln/ultralight_13...

Yeah, I see your point. I'd be surprised of Gaussian Splatting didn't make it into the advertising for Digital Twin services if/when they add it (like Bently's iTwin or Dassault's Virtual Twin). Whether that translates more broadly into the market, I don't know.

On the other hand, I'm playing with the idea of a platform which provides a Gaussian Splat based Digital Twin of an environment so other systems can utilize it to share location-based information. Even though I don't think it'll be possible to build without utilizing Gaussian Splatting; splatting may not end up in any of the pitches or advertising directly.

It's true, Gaussian Splatting is just an alternative to meshing a pointcloud for companies which currently rely on photogrammetry or lidar (Lidar works well as a basis for splatting when there's reference images taken as part of the scan). But I think that misses all the new opportunities that exist with Gaussian Splatting, which really just don't with existing techniques.

Gaussian Splats are able to handle more heterogeneous information sources, allowing more sources to help splat an environment. Devices like drones, surveillance cameras, or autonomous systems can be used to create or incrementally update a Gaussian Splat; and there's interesting work to allow them to locate themselves within the splat, not just to show themselves but also to place vision ML outputs into it (such as object detection or segmentation results).

Up till now nearly all digital representations of physical environments are either based off the original designs (by things like CAD or BIM files), or are an approximation of the environment (from photogrammetry or Lidar scans). CAD and BIM files suffer from drift, the real environment almost never perfectly matches the design files, small (and large) changes are made; and many times those files aren't even available if the structure isn't new. Photogrammetry and Lidar scans struggle because their output is a pointcloud, and it's very difficult to accurately mesh a pointcloud (Matterport only partially solved this problem and sold for $1.6B). Gaussian Splats overcome these issues; they're comparatively easy to generate for any environment, and allow for very accurate and easy viewing from any angle.

I think the Digital Twin space will be turned upside down, and they could potentially even cause huge changes in autonomous and semi-autonomous factories, warehouses, and depots. A single Gaussian Splat could be the source of truth that many autonomous vehicles update through their separate SLAM systems. Operators then would have access to this splat (and it's history) as a source of truth for the environment. Then, using techniques like iComMa[1], it may be possible to directly align XR devices into the Gaussian Splat; allowing operators direct access to location-based information generated by the environment.

That's a lot of words to say: Gaussian Splatting is a very neat new technology that could really underpin many future technologies, I'm really excited about it

[1]: https://yuansun-xjtu.github.io/iComMa.io/