Ideally splitting out the use cases would allow both implementations to be simpler, but that ship has probably sailed.

AI bloats text and every other task it does into convoluted redundant cliches. This is true for text and code. Whether it was written by an AI or not, it's not worth my time. If you wrote it 100% by hand and it still sounds like AI, it's still bad writing and still not worth my time.

Of course, more streams means more resource utilization, there's not getting around that, but that's the cost of parallelism. The use of `yield*` should keep the overhead to a bare minimum. Since the streams are being left alone and aren't consumed until needed, that should preserve some of the back-pressure behavior, although I do need to look into that more deeply.

How the system handles errors probably doesn't have a single solution that works for all frameworks, so I think it should be up to the specific requirements of each use case, but there's also definitely more work to do to explore the options and the patterns.

These are all things I definitely want to hear ideas for as well!

The next thing I'm exploring is applying these patterns to web rendering which will be a real stress test for how they can be used.

Comments URL: https://news.ycombinator.com/item?id=45117242

Points: 4

# Comments: 2

The best way to stop this is to make those safeguards stronger and completely shut down the chat to refer users to seek help from a better service. Unfortunately those services don't really exist yet.

There would be false positives and that'll be annoying, but I think it's worth it to deal with some annoyance to ensure that general purpose AI assistants are not used for counseling people in a vulnerable mental state. They are not aligned to do that and they can easily be misaligned.

When you find a rigid workflow that is both widely applicable and useful, that's how the most valuable companies are made. Those workflows can scale up with little intervention giving them incredibly high yield.

I think the new challenge is introducing flexibility in a controlled manner so we can minimize the added inconsistency needed to achieve broader goals. That way the workflow can find the right balance between robustness and flexiblity for the task at hand.

I'd compare it to being in the room with someone on a conference phone call and they're relaying the conversation to you and them both ways. I would still say you were participating in the call even though you weren't directly on the call.

Also, he did initiate the call so "F-35 pilot held" is imprecise, but not totally wrong. Either way, the pilot was in an active tech support session with the plane engineers, making this one of the most intense tech support calls in history.

https://www.timetler.com/2025/08/19/unlocking-rich-ui-compon...

I'm curious why you decided to go with a DSL instead of embedding an established language?

MDX parses JSX so it's compatible with any JSX runtime, not just react.

You're right that MDX executes arbitrary code because it supports the `import` and string interpolation of MDX and performs unsafe evals.

Because those evals aren't safe to use at runtime, I actually created a library that uses the MDX parser to support the static subset of JSX (which is very similar to HTML making it static and secure): https://www.npmjs.com/package/react-markdown-with-mdx