I have to say, I was a bit flabbergasted recently by a large, articulate comment on HN with the premise "Anti-LLM sentiment within software development is nearly non-existent". Very matter-of-fact, not seeming intended as contrarian.
For lack of a better word, it feels "weird" to read a sentence like that in what appears to not be a troll comment.
They might have solved coding but we’ll see whether they have a handle on debugging code they didn’t have a hand in writing.
We might categorize new code repos into one of three groups:
Class 1: Fully reviewed: Every line is carefully reviewed and understood before being merged. All necessary edits are made.
Class 2: Partially reviewed: Every line is looked at, but is not carefully reviewed or understood before being merged. Edits are sparse, if any.
Class 3: Not reviewed (true vibe coding): Edits are not reviewed (outside of a major accidental deletion). The trust is altogether in the tests. Functional behavior is
all that is reviewed.
Granted, orthogonal adjustments to this grouping are possible, but imho it captures the essence of the process.
The point is to classify each new repo at the time of its creation, then stick with it. Its classification should be documented in its readme.
I predict a new speculative market will emerge where adherents buy and sell misween coded companies.
Betting on whether they can actually perform their sold behaviors.
Passing around code repositories for years without ever trying to run them, factory sealed.
Not just HN. This tweet yesterday says something similar and got 56M views:
https://x.com/mattshumer_/status/2021256989876109403 / https://shumer.dev/something-big-is-happening
I have to say, I was a bit flabbergasted recently by a large, articulate comment on HN with the premise "Anti-LLM sentiment within software development is nearly non-existent". Very matter-of-fact, not seeming intended as contrarian.
For lack of a better word, it feels "weird" to read a sentence like that in what appears to not be a troll comment.
They might have solved coding but we’ll see whether they have a handle on debugging code they didn’t have a hand in writing.
We might categorize new code repos into one of three groups:
Class 1: Fully reviewed: Every line is carefully reviewed and understood before being merged. All necessary edits are made.
Class 2: Partially reviewed: Every line is looked at, but is not carefully reviewed or understood before being merged. Edits are sparse, if any.
Class 3: Not reviewed (true vibe coding): Edits are not reviewed (outside of a major accidental deletion). The trust is altogether in the tests. Functional behavior is all that is reviewed.
Granted, orthogonal adjustments to this grouping are possible, but imho it captures the essence of the process.
The point is to classify each new repo at the time of its creation, then stick with it. Its classification should be documented in its readme.
I predict a new speculative market will emerge where adherents buy and sell misween coded companies.
Betting on whether they can actually perform their sold behaviors.
Passing around code repositories for years without ever trying to run them, factory sealed.