←back to thread

123 points mooreds | 1 comments | | HN request time: 0s | source
Show context
lelanthran ◴[] No.45212622[source]
This works until you get to the point that your actual programming skills atrophy due to lack of use.

Face it, the only reason you can do a decent review is because of years of hard won lessons, not because you have years of reading code without writing any.

replies(7): >>45212731 #>>45212756 #>>45213395 #>>45213636 #>>45213875 #>>45213884 #>>45214429 #
sevensor ◴[] No.45213636[source]
What the article describes is:

1. Learn how to describe what you want in an unambiguous dialect of natural language.

2. Submit it to a program that takes a long time to transform that input into a computer language.

3. Review the output for errors.

Sounds like we’ve reinvented compilers. Except they’re really bad and they take forever. Most people don’t have to review the assembly language / bytecode output of their compilers, because we expect them to actually work.

replies(1): >>45214191 #
ako ◴[] No.45214191[source]
No, it sounds like the work of a product manager, you’re just working with agents rather than with developers.
replies(5): >>45214841 #>>45214888 #>>45215106 #>>45221459 #>>45224563 #
1. didibus ◴[] No.45224563{3}[source]
If you work at "product manager" level, that would be vibe coding, as you prompt for functional and non-functional changes and you review the behavior and characteristics of the program, not the code generated.

I believe the author was trying to specifically distinguish their workflow from that, in that they are prompting for changes to the code in terms of the code itself, and reviewing the code that is generated (maybe along with also mentioning the functionality and testing it).