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 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.

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.