criemen

Assuming you earn enough, throw money at your problems. Many problems can be solved, or made significantly easier by money.

Don't do the research yourself, pay a specialist instead. Missing a winter wardrobe? Find a personal stylist (okay, requires some research to find, but much less than finding fitting wardrobe yourself). They will guide the shopping process, the outcome is most likely better than what you can come up with even with weeks of research. Costs a pretty penny, might feel funny, but it's effective.

Not happy with your art? Get a personal tutor for drawing. Learning a language, but struggling with it? Tutor it is. Learning is so much faster with personalized feedback and accountability, a good tutor provides both.

> Why would someone in China not select Claude?

Because Anthropic doesn't provide services in China? See https://www.anthropic.com/supported-countries

Okay I see, that's a nice secure-by-default point, whereas TS is arguably not secure-by-default.

I don't know Rust, and I'm genuinely curious: How does it improve over that problem?

When you call a REST API (or SQL query for that matter), how does it ensure that the data coming back matches the types?

TS allows you to do parse the JSON, cast it into your target type, done (hiding correctness bugs, unless using runtime verification of the object shape, see sibling comment). Does Rust enforce this?

I'd expect at least API pricing for all major players to be margin-positive. Positive ROI if you include model training cost? Maybe not, but in a hypothetical scenario where all capital for new model training goes away, the latest frontier model weights still continue to exist.

Subscription prices for claude code et. al? No idea.

But why? Training hardware maybe will appear, but everything that's running inference has real, paying customers on it, with current capabilities level. Even if the bubble bursts, why would that demand evaporate? People still would want to use chatgpt, claude code etc., even if they stop getting any better tomorrow.

So far, due to the AI boom, we're lacking:

* HDDs

* SSDs

* DRAM

* GPUs, obviously

* Power to hook up to our datacenters

Anything I'm missing? What a crazy world we're living in.

People need agency, and feel empowered to go forward. I'm not arguing against that interpretation of the post. But having agency doesn't equal a lack of accountability, or being able to explain what you're doing.

In the end, it's a tricky balance between moving fast and slow, which is why no one has found the perfect, long-term viable solution yet.

No, but especially of staff+ engineers I'd expect that they know how to disagree and commit after a reasonable (not too long!) time.

> A discussion about building a specific feature can devolve into reevaluating the entire product roadmap if you let it.

Well, if the product roadmap doesn't hold up to scrutiny, it _should_ be reevaluated. Too often people commit to something, and then continue building it, despite the market realities having shifted underneath them. I see most teams not asking themselves often enough "should we still be doing what we're doing", than the opposite. The sunk cost fallacy is real.

This is the key insight for me about this post, and I fully agree with you.

No collaboration means less opportunities for learning from people (even the post admits!) that are "better at what you are doing than you are", which imo stunts personal growth.

Decision makers need to be clearly appointed, accountable, and empowered to follow through. But that power then also comes with listening to feedback from all relevant parties. As long as they trust that they're being listened to, they don't get a say in the actual decision making process themselves. I also agree about taking reversible decisions faster.

Another point I deeply disagree with is

> collaboration forces the driver to slow down and explain stuff (background, context, their thinking).

Yeah, and that's a good thing. It forces them to properly think through their thoughts, if they can't explain what they want to do clearly and why, it probably shouldn't be done. Quality goes up by slowing down.

I'm not sure about that - every time I copy an object I have to think through what happens, no matter the default semantics. C++ makes the deep copy case easier than other programming languages without top-level built-in support.

Would it be fair to say that things are so complicated (compared to all other programming languages I've used in my professional life), because C++ pre-move semantics defaulted to deep copy semantics? It seems to be set apart in that choice from many other languages.

Oh wow, I never knew! Guess I never read the manpage either.

> modern alternative

Anyone remember top? I was so happy to switch to htop that had colors!

> but for that certain language

What do you mean by that?

Fair enough, it makes more sense in a, say, Haskell-style pure functional language. Instead of getting a general IO monad, you pass in more restricted functionality.

Still, it'd be highly painful. Would it be worth the trade-off to prevent supply chain attacks?

> we should instead isolate every library we import and run it under a sandbox

I don't see how that'd be possible. Often we want the library to do useful things for the application, in the context of the application. What would incentivize developers to specify more fine-grained permissions per library than the union of everything their application requires?

I see more use in sandboxing entire applications, and giving them more selective access than "the entire user account" like we do these days. This is maybe more how smartphones operating systems work than desktop computers?

It's hard for me to say. I don't think you know you're on the S-curve until after the fact.

On the one hand, most models are "good enough" for chatgpt-like usage, and there it's hard to see/feel generation-to-generation improvements. On the other hand, if you look at instruction following, dealing with long context windows, >200 tool call interactions while staying on track, there's still plenty of improvements to be had. So, hard to say where we are.

I tend to use them when I'm looking to buy something of category X, and want to get a market overview. I can then still dig in and decide whether I consider the sources used trustworthy or not, and before committing money, I'll read some reviews myself, too. Still, it's a speedup for me.

> or if it takes a couple of months to fold these advantages back into the frontier models.

Right now, I believe we're seeing that the big general-purpose models outperform approximately everything else. Special-purpose models (essentially: fine tunes) of smaller models make sense when you want to solve a specific task at lower cost/lower latency, and you transfer some/most of the abilities in that domain from a bigger model to a smaller one. Usually, people don't do that, because it's a quite costly process, and the frontier models develop so rapidly, that you're perpetually behind them (so in fact, you're not providing the best possible abilities).

If/when frontier model development speed slows down, training smaller models will make more sense.

In German, "Swiss cheese" is a term that's well known, and doesn't count that kind of amusement.

For example, you could say that something "looks like swiss cheese" when it has a lot of holes in it, like very old clothing. It's often used slightly ironic, but that's not due to what you state.

+1: EdaMagit has been a game changer for me wrt reordering commits, fusing them together, and writing at least 1-2 sentences of proper commit messages after the fact.

I understand where you're coming from, and I'd love to have learned about pre-training vs. off-the-shelf base model too. But

> their own internal benchmark that they won't release

If they'd release their internal benchmark suite, it'd make it into the training set of about every LLM, which from a strictly scientific standpoint, invalidates all conclusions drawn from that benchmark from then on. On the other hand, not releasing the benchmark means they could've hand-picked the datapoints to favor them. It's a problem that can't be resolved unfortunately.

This is not true, on the route Denmark/Germany there was no decoupling involved - the train drives onto the ferry, and drives off the ferry afterwards.

No - it's a rather short train, only a few carriages, and the engine is mostly integrated into the carriages I believe.

> I doubt that they carry the engine across by ferry?

I don't know about this specific instance, but the Germany-Denmark train-on-a-ferry carried the whole Diesel-powered train, engine and all. It drove onto the ferry on its own, and left it on its own as well.

Great article, and I mostly agree.

I want to nitpick on

> Don’t review with a “how would I write it?” filter

_Thinking_ about "how would I write it?" when reviewing code catches a lot of stuff for me - I want to be able to come up with how I'd do it, see how the PR does it, and then check if the approach matches. If not, there's something to be learned and explained here. Although, all of that is in my head! If I come to the conclusion that the presented approach is wrong or inferior in an objective way (say, doesn't handle corner cases neatly or at all), I'll comment. Otherwise, let people do their thing!

So, I agree with the point of not using this to generate a lot of comments, but I do believe in it as a useful technique to engage the brain, instead of just loosely scrolling over the diff.

I don't think macbooks have a GPS chip built-in, isn't it only wifi geolocation?

How should they do that? I hear that phrase, and it's easy to agree to, but how would it look in practice?