bblcla

Fixed now! :)

hey! I saw this and liked it a lot! It’s impressive how you pull in all the routes per tail - we considered doing it but were worried it would be too expensive. Definitely opens up cool options though.

> Feature request: Put a disclaimer on the fleet page that the tracking is limited. Or pull enough data to say "28 airframes of 47 are starlink capable" which is what I think most people will be looking to know in the fleet info.

Oh, this one is very doable and makes sense! We track this internally anyway so it's just a matter of surfacing it on the fleet information.

Great questions!

> how stale does the tail assignment data get in practice, and do you have a way to detect when an enthusiast spreadsheet goes unmaintained?

These are updated almost every day so far, so they seem very up-to-date. Internally we track all changes/removals, so I'm not that worried about spreadsheets being abandoned yet. It's a good thought though.

> And what happens to your probability estimate when an airline swaps aircraft last minute, which seems to happen pretty often on regional routes?

Honestly our estimate right now is pretty crude. At the scale we're at right now it works, but I think you're right that we could make this more accurate by tracking equipment swaps & really drilling into the details of which aircraft get assigned to which routes.

Oh that's a cool idea! We wanted to do a variant of this, will add it to the list. The tricky part for us is getting a canonical list of all flights + body types on it.

> And it looks like all of their E175s have Starlink

Not quite sorry, we only track the frames that do have Starlink. But if you check back a few days beforehand you can see if yours matches!

I'm not actually sure myself, but I was really surprised to learn how profitable it is. SpaceX made $15b of revenue last year and $8b of profit. Starlink was 60-80% of that!

It turns out the demand for really good internet everywhere is huge.

> The annoying this is I live by a UA hub and UA doesn't fly regional planes between UA hubs.

Oh I actually didn't know this! Do you know why?

That's frustrating. It's possible their link was down for some reason - airline maintenance issues happen all the time. :(

Dwarkesh definitely got big in Silicon Valley from his AI podcasts. He's one of the few people who can get famous researchers on and also have them say something genuinely new.

After that, he become well-known to the general public through his Sarah Paine podcasts (which are excellent).

great idea, actually, I just didn't think of it!

Arguably linting is a kind of abstraction block!

I agree! Like I said at the end of the tool, I think Claude is a great tool. In this piece, I'm arguing against the 'AGI' believers who think it's going to replace all developers.

(Author here)

I have! I agree it's very good at applying abstractions, if you know exactly what you want. What I notice is that Claude has almost no ability to surface those abstractions on its own.

When I started having it write React, Claude produced incredibly buggy spaghetti code. I had to spend 3 weeks learning the fundamentals of React (how to use hooks, providers, stores, etc.) before I knew how to prompt it to write better code. Now that I've done that, it's great. But it's meaningful that someone who doesn't know how to write well-abstracted React code can't get Claude to produce it on their own.

(Author here)

> I'm not entirely convinced by the anecdote here where Claude wrote "bad" React code

Yeah, that's fair - a friend of mine also called this out on Twitter (https://x.com/konstiwohlwend/status/2010799158261936281) and I went into more technical detail about the specific problem there.

> I've seen Claude make mistakes like that too, but then the moment you say "you can modify the calling code as well" or even ask "any way we could do this better?" it suggests the optimal solution.

I agree, but I think I'm less optimistic than you that Claude will be able to catch its own mistakes in the future. On the other hand, I can definitely see how a ~more intelligent model might be able to catch mistakes on a larger and larger scale.

> I expect that adding a CLAUDE.md rule saying "always look for more efficient implementations that might involve larger changes and propose those to the user for their confirmation if appropriate" might solve the author's complaint here.

I'm not sure about this! There are a few things Claude does that seem unfixable even by updating CLAUDE.md.

Some other footguns I keep seeing in Python and constantly have to fix despite CLAUDE.md instructions are:

- writing lots of nested if clauses instead of writing simple functions by returning early

- putting imports in functions instead of at the top-level

- swallowing exceptions instead of raising (constantly a huge problem)

These are small, but I think it's informative of what the models can do that even Opus 4.5 still fails at these simple tasks.

Stardrift (https://stardrift.ai) | Founding Engineer | Onsite - SF | Full time

Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3.

We are building a world-class travel agent experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.

You'll tackle everything from optimizing LLM performance and building evals to integrating with APIs for rail and flight networks around the world. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working with me & the rest of the founding team.

Here's a tech blog we wrote about some of the systems engineering we do: https://stardrift.ai/blog/streaming-resumptions.

You can find more info at https://www.ycombinator.com/companies/stardrift/jobs/nC7cjhB.... Email [email protected] to apply.

Stardrift (https://stardrift.ai) | Founding Engineer | Onsite - SF | Full time

Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3-4. (Fun fact: I got my first coding job through 'Who is hiring?', almost 12 years ago!)

We are building a world-class travel search experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.

You'll tackle everything from optimizing LLM performance and building evals to integrating APIs like Amadeus and Duffel. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working shoulder-to-shoulder with me & the rest of the founding team.

More info at https://www.ycombinator.com/companies/stardrift/jobs/nC7cjhB....

Please reach out to [email protected] to apply.

Unfortunately, no. It was a private talk.

Tyler Cowen did an 'ask me anything' at Jane Street when I interned in 2016. One of the interns asked him exactly this: "What do you think of the fact that we all work here instead of, I don't know, curing cancer?"

He replied with, roughly, "Those of you who work here probably couldn't do anything else other than perhaps math research. Arguably, working here is the economically efficient use of your time."

I think about whenever I see a comment like this. Quant firms select for a very specific set of skills. In particular, I've found that many traders/software engineers in quant are very smart but not very self-directed. Places like Jane Street work well for people who can excel, but only when given a lot of structure and direction. I think this is not unrelated to why so many people 'accidentally' end up as traders after going to an Ivy League school!