Just answering with a possibility here, but they could be seeking freedom from liability for failure to moderate content or ensuring their service is "not harmful". If it's only for consenting adults, and every adult can be pinned down with an identity, whatever happens can have the blame assigned away from meta.
I agree with what you're saying about writing something twice or even three times to really understand it but I think you might have misunderstood the WET idea: as I understand it, it's meant in opposition to DRY, in the sense of "allow a second copy of the same code", and then when you need a third copy, start to consider introducing an abstraction, rather than religiously avoiding repeated code.
Personally, even for a prototype, I'd be using functions immediately as soon as I saw (or anticipated) I needed to do same thing twice - mainly so that if I want to change it later there is one place to change, not many. It's the same for production code of course, but when prototyping the code structure may be quite fluid and you want to keep making changes easy, not have to remember to update multiple copies of the same code.
I'm really talking about manually writing code, but the same would apply for AI written code. Having a single place to update when something needs changing is always going to be less error prone.
The major concession I make to modularity when developing a prototype is often to put everything into a single source file to make it fast to iteratively refactor etc rather than split it up into modules.
> mainly so that if I want to change it later there is one place to change, not many
But what happens when new requirements come in for just one of the things? If you left them separate, it's an easy change of a few lines. If you created an abstraction, now you either have to add a bunch of if statements, or spend time undoing the entire abstraction that you spent X amount of time creating.
If a bunch of other code has built up around that abstraction, undoing it can become a serious chore. I've worked on apps that had way too many premature abstractions, and we just had to live with it because it would be too risky and onerous to try to undo them.
In my experience, it's generally an order of magnitude easier to add an abstraction to a mature app when you get tired of making changes in multiple places, than to remove one when the app evolves and you realize these things aren't actually that similar. Also when you wait to abstract, you might see a better way to do it, or how to reduce the scope so that you're using composition to share a bunch of smaller pieces vs. sharing the entire page/object/interface/endpoint/etc.
Obviously, this isn't a blanket rule. There's an aspect of soothsaying to guess which things might diverge and which are likely to spawn a lot more similar copies.
> But what happens when new requirements come in for just one of the things?
I guess it could happen, but that depends on your mental model when coding - if you're just pattern matching similar chunks of code (which are not being used in a semantically identical way) then all bets are off, although that seems a very alien concept of how someone might code.
OTOH, if you have a higher level mental model of what you are doing then it's not a matter of "this looks like common code" but rather "i need to do the exact same operation" (same inputs/outputs/semantics) here. Maybe I'm expressing it poorly, but I can't recall ever having to fork a function because requirements at two call sites just diverged.
The danger with people that claims to follow DRY is that they don’t check first that they are repeating yourself. As soon as they’re encounter similarity, they assume equality and rush to abstract it. But if one knows the domain enough to know that some logic is the same, not just similar, then no need to write it twice first.
I don't think this diminishes your point, but, for a thing like memory, your father may be maintaining it by insisting on relying on it. It may diminish regardless, but its diminishment may slow down.
At work, we are in a certain kind of race. In life, we are in a certain other kind. To paraphrase a recent Brandon Sanderson talk about creativity in an era where AI can outpace and possibly soon, out-quality a professional, "The work you do on _you_ can be _the art_."
Strongly agree! As someone who has been caring for a parent with dementia, it's definitely a use or lose it kind of situation. See also the studies on long term cognitive health in London cab drivers
This is the take, very well said. I've been trying to use analogies with cars and cabinet making, but building a house is just right for the scale and complexity of the efforts enabled, and the ownership idea threads into it well.
When you spend Canadian dollars at a business owned by a Canadian, you're sending that owner and the Canadian government your money, in exchange for their goods or services, normally at a surplus of value for them. You are 'helping' them; you are 'investing' in the Canadian economy. You are justifying the existence of their business and the jobs of the people who work there.
Especially insofar as you're making this choice versus American options, you are putting money into the hands of Canadians rather than Americans. This is the underlying concept behind boycotts and voting with your dollars or feet.
You or a business with legal owners can have a bank account, and you can give access to that account to an agent, but real banks work in the real world, and "know your customer" regulations need a real person somewhere in the chain.
I wish I could properly cite it, but one of my favorite HN comments recently was, to paraphrase, "thing, but from the Internet". Which is to say that old rules don't apply, for some reason.
Things are going to get weird when the automatons become sophisticated enough to pull off identity theft while unsupervised.
Putting a brick on the gas pedal is obviously negligent. Whereas it is not so obvious that running a random script from github that spins up an agent with access to your home folder could lead to real world financial crimes.
> Whereas it is not so obvious that running a random script from github that spins up an agent with access to your home folder could lead to real world financial crimes.
disagree, and the courts will likely take this position as well. ignorance has never been a defensible strategy to avoid liability.
pick up a detonator, it's up to you to understand where the bombs are positions what's in the blast range.
Again, I never used the term "liable". You introduced that. I spoke of criminal negligence.
And I don't believe your claim of liability generalizes. If someone else set up the detonator and then I pushed the button without realizing what it was I don't believe I'd be liable.
The party that set it up might be, but it gets really complicated and messy because it depends on the specific circumstances of all involved parties.
If A sets it up in a manner believed to be safe, B moves something in good faith which unintentionally makes things unsafe, and then C comes along and triggers it without realizing, you might well end up with a situation where no one is considered liable.
That might be true, but it doesn't have to be immediately true. It's an arbitrage problem: seeing a gap, knowing you can apply this new tool to make a new entrant, making an offering at a price that works for you, and hoping others haven't found a cheaper way or won the market first. In other words, that's all business as usual. How does Glad sell plastic bags when there are thousands of other companies producing plastic bags, often for far, far less? Branding, contracts, quality, pricing -- just through running a business. No guarantee it's gonna work.
Vibe-coding something isn't a guarantee the thing is shit. It can be fine. It still takes time and effort, too, but because it can take lot less time to get a "working product", maybe some unique insight the parent commenter had on a problem is what was suddenly worth their time.
Will everyone else who has that insight and the vibe coding skills go right for that problem and compete? Maybe, but, also maybe not. If it's a money-maker, they likely will eventually, but that's just business. Maybe you get out of the business after a year, but for a little while it made you some money.
> That might be true, but it doesn't have to be immediately true. It's an arbitrage problem: seeing a gap, knowing you can apply this new tool to make a new entrant, making an offering at a price that works for you, and hoping others haven't found a cheaper way or won the market first. In other words, that's all business as usual.
I'm hearing what you are saying, but the "business as usual" way almost always requires some money or some time (which is the same thing). The ones that don't (performance arts, for example) average a below-minimum-wage pay!
IOW, when the cost of production is almost zero, the market adjusts very quickly to reflect that. What happens then is that a few lottery ticket winners make bank, and everyone else does it for free (or close to it).
You're essentially hoping to be one of those lottery ticket winners.
> How does Glad sell plastic bags when there are thousands of other companies producing plastic bags, often for far, far less?
The cost of production of plastic bags is not near zero, and the requirements for producing plastic bags (i.e. cloning the existing products) include substantial capital.
You're playing in a different market, where the cost of cloning your product is zero.
There's quite a large difference between operating in a market where there is a barrier (capital, time and skill) and operating in a market where there are no capital, time or skill barriers.
The market you are in is not the same as the ones you are comparing your product to. The better comparison is artists, where even though there is a skill and time barrier, the clear majority of the producers do it as a hobby, because it doesn't pay enough for them to do it as a job.
All fair points, I think I agree with your take overall but we might each be focusing on situations involving different levels of capital, time, and skill: I'm imagining situations where AI use brought the barrier down substantially for some entrants, but the barriers still meaningfully exist, while it sounds to me like you're considering the essentially zero barrier case.
My Glad example was off the cuff but it still feels apt to me for the case I mean: the barrier for an existing plastic product producer who doesn't already to also produce bags is likely very low, but it's still non zero, while the barrier for a random person is quite high. I feel vibe coding made individual projects much cheaper (sometimes zero) for decent programmers, but it hasn't made my mom start producing programming projects -- the barrier still seems quite high for non technical people.
I dunno about the Glad bag analogy, and now I'm not sure that the artist analogy applies either.
I think a better analogy (i.e. one that we both agree one) is Excel preadsheets.
There are very few "Excel consultants" available that companies hire. You can't make money be providing solutions in Excel because anyone who needs something that can be done in Excel can just do it themselves.
It's like if your mum needed to sum income and expenditures for a little side-business: she won't be hiring an excel consultant to do write the formulas into the 4 - 6 cells that contain calculations, she'll simply do it herself.
I think vibe coding is going to be the same way in a few years (much faster than spreadsheets took off, btw, which occurred over a period of a decade) - someone who needs a little project management applications isn't going to buy one, they can get one in an hour "for free"[1].
Just about anything you can vibe-code, an office worker with minimal training (the average person in 2026, for example) can vibe-code. The skill barrier to vibe-coding little apps like this is less than the skill barrier for creating Excel workbooks, and yet almost every office worker does it.
[1] In much the same way that someone considers creating a new spreadsheet to be free when they already have Excel installed, people are going to regard the output of LLMs "free" because they are already paying the monthly fee for it.
edit: I took too long to write this :)