Interesting… thanks for open-sourcing it. I have some ideas to contribute based on the open issues.

the AI agent use case is the one that got me. i've been writing generated code to temp files and then cleaning up after and it always felt wrong. keeping it in memory and importing directly makes so much more sense. haven't tried this yet but the testing example with the using statement is really clean. no more forgetting to delete temp dirs in CI.

Great read.

yeah, that's the gotcha nobody talks about. we ended up moving triggers to async workers with a separate queue to decouple from the write path. saved us from that exact scenario.

Hitting this exactly. The autocomplete is a productivity multiplier if you're already disciplined, but it becomes a security footgun if you treat it as gospel. What actually worked for me: disabled inline suggestions entirely. Use Cursor's chat for architecture decisions and code review instead. The latency forces you to think before accepting. On your specific examples, those aren't Cursor failures. Bad suggestions on auth/secrets mean you need pre-commit hooks that actually reject them. That's not optional with any AI tool, or without one. The "review will catch it" assumption breaks at velocity. Automate the catches instead.

Agree on trace viewer being superior. Playwright's time-travel debugging is honestly a game changer for complex flows. Cypress screenshots feel like a band-aid by comparison.

Yeah, that's rough but textbook cold start problem. Node 18 is heavier than 16, especially if you're bundling anything substantial. Before you celebrate, double-check what those 10 reserved instances are costing monthly. Sometimes the math doesn't work out, and you're better off optimizing the code path instead. Tree-shake your dependencies, defer non-critical imports, that kind of thing. Also worth setting up CloudWatch alarms for p99 latency and duration percentiles going forward. Catch drift before it becomes a 3am incident next time.

agree on the priority shift, but i'd push back on skipping unit tests entirely. they're cheap to run in ci and catch the dumb stuff fast. the real win is integration + e2e for the flows that matter most, yeah.

totally agree on the overhead cost. we just switched to this at $job and found the real win was batching related jobs, not necessarily splitting everything. the context startup tax is real, especially on smaller runners.

Yeah, fair point on dependency hell. But independent packages force you to actually define boundaries and APIs clearly. Monorepos let you get lazy about it. The versioning is just a symptom.