martzoukos

Yup, one more of us.

Can it turn to snow when it's Christmas?

Oh, that doesn't seem so far

First of all, congratulations on asking this question, it seems that everyone is an AI expert these days and it takes courage to admit you're not one of them (neither am I or most of of everyone).

In my little experience, what I've seen work is that you need to provide a lot of constraints in the form of:

- Scope: Don't build a website, but build a feature (either user facing or infra, it doesn't matter). I've found that chunking my prompts in human-manageable tasks that would take 0.5-1 day, is enough of a scale down.

- Docs .md files that describe how the main parts of the application work, what a component/module/unit of code looks like, what tools&technologies to use (and links to the latest documentation and quickstart pages). You should commit these to code and update them with every code change (which with Claude is just a reminder in each prompt).

- Existing code, if it's not a greenfield project.

It really moves away from the advertised paradigm of one-shot vibe-coding but since the quality of the output is really good these days, this long preparation will give you a production ready output much sooner than with traditional methods.

OH MY GOD THE SOUNDS IN THE VIDEOS . I feel like I'm pressing the buttons myself.

Soon we'll be creating black hole simulations to run a browser effect.

I guess that there is no streaming option for sending generated tokens to, say, an LLM service to process the text in real-time.

"The problem is deeper than just visual noise, it's a broken physical promise". This sentence is so short and clear, the opposite of what this new design language seems to be.

AI does a pretty good job at helping you learn architecture, though.