wesselbindt

This terrifies me. Assume the following:

- Publicly funded researchers are on the verge of a breakthrough on some type of very important medicine. Cure for diabetes let's say.

- These researchers use Claude for some stuff. Maybe cleaning up the wording in their paper, finding relevant work to cite, whatever.

- Anthropic notices their work, and puts an army of agents on scooping them. These agents are able to make use of the researchers as yet unpublished work.

- Anthropic scoops the publicly funded researchers and patents the diabetes cure.

- Rather than being available at low prices, the cure for diabetes is put behind a paywall.

Here the stakes are much higher than the ones in the mathematical scenario we've already seen play out. We're talking life or death shit, rather than some ethical or philosophical questions about what is math really or whatever.

Don't tell me a for-profit company would never do this. We've all seen worse.

That's always been the case though. Much of our job is figuring out as quickly as possible how wrong we are and in what way. And the best way to do that, now and 5 years ago, is the scientific method. Try something, and then listen to your users to hear what sucks and why, and then adapt.

Believing you can figure out the right requirements through a lot of thinking, analysis, and talking is called the waterfall approach, and it's as wrong now as it was four decades ago.

I think this solves the problem at the wrong level. Ultimately, if you can make the licensing model work (and you can), it is far more profitable than an ownership model. As such, in a system where the scoring function is profit, the system will naturally tend toward a licensing model. An example of this would be operating at a loss for a while to outcompete competitors operating on an ownership model, to the point where they become negligible, so you can crank up the prices in a market that has become dependent on a licensing-based oligopoly, and rake in the profits.

To disrupt this natural tendency, you need an external influence which is not beholden to this scoring function. A good example (but not the only one) of such an external influence would be government regulations.

You could try to influence the cycle as consumers, but there are two significant roadblocks for this approach. Firstly, consumers are highly decentralized, and heterogeneous in their beliefs and actions. Sure, _you_ may understand and believe that a licensing model is bad, but how about the billions of others who are less politically engaged? The second is that consumers operate largely in the same profit driven system as the corporations we're trying to change. It takes a very principled individual to buy gta 6 at a 50% markup just so they can -own- the game rather than just rent it indefinitely.

I don't know of any instances in history of consumers making any meaningful impact in this way. Tons of examples of government regulation effecting meaningful change though.

I think society should be structured in such a way as to incentivize contributing to society. Heal the sick, get rewarded, feed the hungry, get rewarded, teach the ignorant, get rewarded. Own a thing; no reward as far as I'm concerned. Owning stuff _is_ the reward, not something to be incentivized. It's its own incentive. Why should society give a gold star to someone for owning a toothbrush, or a house? They're a reward in themselves.

Fair point! This post is not a load bearing and accurate description of Claude's workings, it's satire.

> The way you test code cannot (and should not) be decoupled by the way in which you architect the code itself.

I'm not sure I fully understand. In my view, it's pretty evident that tests should test behavior and not structure. Coupling to implementation details is unavoidable but should be managed, and ideally minimized, to keep the test suite robust and maintainable.

Given the choice between a test suite that monkey patches out some dependency (redis, say) on a per-test basis, and one which substitutes a fake for this dependency in some centralized composition root, which one do you prefer, and why?

Thank you, I appreciate you sharing this very much! I wish I could read the entire chat, but I imagine there might be some NDA stuff in there if you talk abt real world experiences.

> Teams, em dash bla bla bla em dash have quietly bla bla bla. It's not this, it's _that_.

I find it hard to read articles where the agentic writing is this obvious. It's a distraction from the message of the text, which I'm sure is worth my time. Is there no way to stop generated writing from sounding like this?

So, I get the idea of having a layer of abstraction between your tests and the system under test. You decouple _what_ is being done from _how_ it is done, which leads to robust, easily maintained, and even more re-usable test suites. I've seen it in action, it's a great idea, I've reaped the benefits myself. Great stuff.

What I've never really understood is why some people choose natural language for the abstraction. It just seems like such an odd and expensive choice. Most of the layers of abstraction we add in our codebase are written in the programming language of choice itself, they're functions, classes, what have you. But for this one specific flavor of abstraction, folks reach for natural language.

The one potential benefit I could think of for this over a more standard DSL is that non-technical colleagues would be able to read or even write these specs. But in practice I've only seen this pan out once in my life, and that was with a more traditional DSL rather than natural language.

Is there a hidden benefit I'm overlooking?

Literally everything except the media writing non-sensationalist headlines about science.

> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?

There's probably a lot wrong with the "coding was never the hard part" take, but this quote right here shows that the author is not willing to engage with the actual idea that folks who say this are espousing. Because if the author was discussing these ideas on good faith, he'd know that the answer is obvious: there's much, much more to a software engineer's job than just coding, and that other stuff is very hard to do well, and people pay for that.

Again, I'm not saying the "coding was never the hard part" folks are right, but I really, really hate straw men.

Exactly, I feel the same way, and was surprised to see so few people pointing this out. Forest vs desert I guess.

Ok, thanks for explaining! Doesn't really explain how the wc eend expression _doesn't_ apply here (which would be hard to do, because it _does_ apply, since this is someone praising their own work, and it doesn't get more straightforwardly applicable than that), but I do really appreciate the effort.

I always thought it was common sense and just basic critical thinking to take people paid by Anthropic praising products of Anthropic with a grain of salt (and let's be clear, that's what this is), but apparently it's not.

I don't see how Claude code being a widely used product is relevant to the person who orchestrated the Rust rewrite of bun saying that the orchestration of the Rust rewrite of bun went well. Wc eend is a widely used product as well, if that helps.

Ah, for context, which I suspect you may be unaware of, Jarred (the person who said the rewrite to rust went well) is the creator of bun, and the guy behind the rewrite.

It was a commercial slogan for a toilet cleaning agent. An English equivalent would be "mr clean recommends you use mr clean". Today, it is used to point out when someone tells you they themselves delivered good work. Anytime you'd use the meme of Obama giving himself a medal, you could use this phrase.