> Otherwise you are no better than someone at an intersection with a bottle of Windex and a squeegee who, unsolicited, cleans a windshield and then demands the driver to pay for it.
I am struggling to see how this analogy is relevant. It seems more like a knee jerk to the use of "force" in the headline. TFA seems to be talking about a potential way to _generate revenue_ through side channels that are deemed valuable by the users. This is clearly different from "demand the user to pay for it" as the analogy would imply.
Open source contributors don't come unsolicited to "clean the users' windshields". They just write stuff that they find useful and the inherent value of that work attracts other developers as much as users. And then the whole thing grows too large to maintain without serious money.
If the language were centered around donations (charitable gifts) instead of revenue and the implicit expectations that go with it, then I might take a different view.
> It's asking somebody who writes code to now read and debug others code.
That's exactly right. Open source projects are currently drowning under LLM generated PRs, where those who used to write code are simply punting that work to AI, but still expecting others to review it. It's not okay to expect such a free lunch. If you moved the labour of writing code one step away, then you are yourself the first line of defence now, so you better start reviewing code that you claim to be yours.
That's what I do and expect my colleagues to do. Even before LLMs I was reviewing my own PRs before submitting them to others. I still do that. I work closely with Claude to create something good that I'm happy with, then I review it and test it to ensure it's good. And only then do I submit the PR to colleagues for final review.
I expect the same from colleagues, I'm not interested in treating them as a middle man between me and Claude.
> Makes me wonder if a solar system wide civilization, with trillions of beings, wouldn't invest in ships to go to the next system, extract resources, and create a stream of resources ships going back to the original solar system.
> If you weren't able to build it before then you aren't able to properly verify it
GP said "couldn't dream of building". To make an analogy, I wouldn't dream of building a house if I had to do every bit of brick-laying myself. But with others doing what I can't do, I can indeed dream of building a house and I do know how to verify that the house was built to satisfy my dream.
This analogy is ironic to me. For most people, building a dream house and verifying it means hiring someone else who is accountable for it being built to code etc.
This is exactly the naive gap that is happening with AI. There is no trusted middleman who does the verification and takes the burden of accountability. The AI vendor tries to sell it like magic but with a disclaimer that is is merely entertainment. The user tries to pretend they are reviewing, but often is just implicitly trusting the tool to do right by them on things they have no real capacity to evaluate.
> There is no trusted middleman who does the verification and takes the burden of accountability.
It's a great example of a project that needs accountability, but there's also thousands of other projects that need absolutely no accountability.
It's all relative to the stakes. The lower the stakes the less informed verification is needed.
The real trick is being informed enough on the boundaries to know where it matters. In the construction analogy, you need to be informed enough to know that a house is a bad idea since there are safety concerns. However building something small and non-load-bearing is probably fine to "vibe".
Eg there's no expertise needed to judge a garden trellis or 2 foot picket fence. It either works or it doesn't, and if it fails down the road there's no harm.
A house is a good analogy here. You can verify that a house is built to satisfy your dream. You can't likely verify that a house won't collapse in the middle of the night or during a storm/quake/etc. Once no human understands how the house is built anymore, we will need other ways to verify that or just trust it's done right.
It could just be that each of the two reviewers is merely focussing on different sides of the same coin? I use Claude all the time. It saves me a lot of effort that I would have otherwise spent in looking up specific components. The magically autocompleted pieces of boilerplate are a tangible relief. It also catches issues that I missed. But when it is wrong, it can be subtly or embarassingly or spectacularly wrong depending on the situation.
> I can still run 2-3 clients almost 24/7 pumping out features.
Honest question. How does one do that? My workflow is to create one git worktree per feature and start one session per worktree. And then I spent two hours in a worktree talking to Opus and reviewing what it is doing.
The comedy/tragedy of this is; whenever I talk to people outside of engineering at social gatherings, this is what they do. Tell me their resume and accomplishments. I’m like, can we just a have a conversation please?
I always asks the question “what keeps you busy”? People think my wife and I are retired because of how often we travel. I say I’m not, I work remotely and try to keep the conversation away from work.
I am hearing this term for the first time but I love it. It is novel and creates a picture. Exactly what Scott Adams says about labels used for persuasion. I usually say "highly trained autocomplete" in discussions at work, but I am going to say "stochastic parrot" from now on.
oh, OK. You should google the term to see where it comes from. it's from someone who is essentially an anti-LLM activist and it's meant as a slur. That's likely why people consider it to be a slur, due to its origins.
I am struggling to see how this analogy is relevant. It seems more like a knee jerk to the use of "force" in the headline. TFA seems to be talking about a potential way to _generate revenue_ through side channels that are deemed valuable by the users. This is clearly different from "demand the user to pay for it" as the analogy would imply.
Open source contributors don't come unsolicited to "clean the users' windshields". They just write stuff that they find useful and the inherent value of that work attracts other developers as much as users. And then the whole thing grows too large to maintain without serious money.
reply