caijia

I've already be patient when claude code always signs my commits as co-author by defualt. Yes, it is.

But I'm also paying the plan. Theres something odd about a tool which i paid for using my output to AD itself.

UML is a smart call, and reminds me when I built an inventory and shift scheduling system on wordpress in 2017.

somtimes the "wrong" / "old" tool for some job is exactly right for you if you really understand it. UML is old but fits here.

15 years is long enough to call memory about a lot of things.

One angle nobody's mentioned: this breaks pexpect-based automation scripts. A lot of Python deployment tooling (Fabric, Ansible's become_pass, custom provisioning scripts) uses pexpect to detect the sudo prompt by matching the ":" pattern and checking that no output follows. Asterisk feedback changes the output pattern.

Not a reason to keep silent passwords — it's the right UX change. But worth knowing if you maintain automation that interacts with sudo prompts over SSH.

jandrewrogers' point about cache replacement pathology in graph traversals is the kind of thing you only learn after burning real hardware cycles. I hit similar issues using Neo4j for knowledge graph queries — once traversal depth exceeded 4-5 hops, latency became unpredictable regardless of data size.

The embeddable angle is interesting though. For small-to-medium graphs (< 10M edges) that live in a single process, these scalability concerns matter less, and the developer experience of "just add a dependency" beats running a separate database server.

Curious about the headless story. The "Photopea of video editing" comparison is apt — Photopea's real moat ended up being the API and programmatic access, not just the browser UI. Companies embed it for automated image processing workflows.

For a browser-native NLE, the killer feature might not be the timeline UI — it could be exposing the WGPU rendering pipeline as an API that other tools can call. Imagine CI pipelines that render video assets without needing FFmpeg on the server.

The vibe coding question is interesting but I think the real risk for projects like this isn't how the code was written — it's test coverage. A LocalStack replacement lives or dies by API compatibility. If the S3 presigned URL behavior differs slightly, your integration tests pass locally but break in prod.

What I'd want to see before using this: a compatibility matrix showing which API operations are covered, ideally verified against the official AWS SDK test suites for each service.