[joshribakoff]

I clicked out of the article since it starts out with a contradiction.

Experienced engineers can successfully vibe code? By definition it means not reading the output.

If you’re not reading your output, then why does skill level even matter?

[rjh29]

The definition of 'vibe code' is somewhat nebulous at the moment. For many it means "only look at the end product (website) and use prompts to fix it" but for others it means "mostly don't hand-code anything, but check the diffs".

[NitpickLawyer]

> If you’re not reading your output, then why does skill level even matter?

Few thoughts here.

Experience helps you "check" faster that what you asked for is actually what was delivered. You "know" what to check for. You know what a happy path is, and where it might fail. You're more likely to test outside the happy path. You've seen dozens of failure modes already, you know where to look for.

Experience also allows you to better define stuff. If you see that the output is mangled, you can make an educated guess that it's from css. And you can tell the model to check the css integration.

Experience gives you faster/better error parsing. You've seen thousands of them already. You probably know what the error means. You can c/p the error but you can also "guide" the model with something like "check that x is done before y". And so on.

Last, but not least, the "experience" in actually using the tools gives you a better understanding of their capabilities and failure modes. You learn where you can let it vibe away, or where you need to specify more stuff. You get a feeling for what it did from a quick glance. You learn when to prompt more and where to go with generic stuff like "fix this".

[blargey]

Don't you think "having a concrete idea of what sort of code change / end behavior you're looking for" affects the prompts and LLM output?

[wiseowise]

Do apply the same logic to conductors too?