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 leila@stardrift.ai 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 leila@stardrift.ai 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!

1. It looks like Syncthing is an application that lets you sync files? Moonglow runs one layer below - we call cloud apis for you, to set up and connect you to a remote Jupyter kernel.

2. I think the serverless here is actually pretty literal - you don't have to think about or spin up a Jupyter server. We normally describe it as 'run local jupyter notebooks on your own cloud compute,' which I think might be a little more clear.

Not exactly. Brev.dev helps you set up a Jupyter server, but you still need to set up your connection to it yourself. It's also mostly designed to run on the browser.

Moonglow abstracts over this, so you don't need to think about the server connection details at all. We're aiming for an experience where it feels like you've moved your notebook from local to cloud compute while staying in your editor.

Excited to hear that!

There's no SSH keys to store - we start a tunnel from the remote machine and connect to that.

Yeah, I agree! We looked into integrating Moonglow with academic clusters, because many of my ML PhD friends complained about using them. We unfortunately haven't found a good generalized solution, so I think VSCode's remote SSH + manual server management is probably the best option for now.

We make sure the remote containers have CUDA/Pytorch/Numpy/Matplotlib set up if you're using a GPU-based machine. It's actually far easier for me to run ML-based code through Moonglow now than on my Macbook - it's really nice to start with a clean environment every time, instead of having to deal with dependency hell.

We don't yet transfer the python environment on the self-serve options, though for customers on AWS we'll help them create and maintain images with the packages they need.

I do have some ideas for making it easy to transfer environments over - it would probably involve letting people specify a requirements.txt and some apt dependencies and then automatically creating/deploying containers around that. Your idea of actually just detecting what's installed locally is pretty neat too, though.

Cool! We actually don't do port forwarding over SSH, we do it over an ngrok-like solution that we forked/modified. I looked at a few options while we were designing this, including Tailscale and ngrok, but none of them exactly suited our needs, and the pricing would have been prohibitive for something that's a pretty core part of our product.

OpenZiti looks really cool though - I'll take a look!

I'm not super familiar with dbx (though its docs at https://docs.databricks.com/en/archive/dev-tools/dbx/dbx.htm... suggest it's deprecated).

However, looking at its replacement here (https://docs.databricks.com/en/dev-tools/bundles/index.html) - I think we're trying to solve the same problems at different levels. My guess is Databricks is the right solution for big teams that need well-defined staging/prod/dev environment. We're targeting smaller teams that might be doing more of their own devops or are still at the 'using a bash script to run notebooks remotely' stage.

A lot of the people we've talked to who get the most value out of remote compute are doing really intensive stuff - they need server-level resources far beyond what you can find on a consumer laptop!

Hopefully someday you'll have 8 H100s on your Macbook, but I think we're still a long way away from that.

I don't think so, if that jupyter command just runs against your local servers. We register the moonglow remote servers with VSCode through the extension, and my guess is we'd need to do something similar with Zed.

Ah, yeah, I misspoke, sorry. I was aware of that feature, but everyone I've talked to said it's so annoying to use they basically never use it, so I didn't think it was worth mentioning.

The big reason it's annoying is because (I believe) Colab still only lets you connect to runtimes running on your computer - which is why at the end at the end of that article they suggest using SSH port forwarding if you want to connect to a remote cluster. I know at least one company has written a hacky wrapper that researchers can use to connect to their own cluster through Colab, but it's not ideal.

I think Moonglow's target audience is slightly different than Colab's though because of the tight VSCode/Cursor integration - many people we've talked to said they really value the code-complete, which you can't get in any web frontend!

Thanks!

The big difference is that Google Colab runs in your web browser, whereas Moonglow lets you connect to compute in the VSCode/Cursor notebook interface. We've found a lot of people really like the code-completion in VSCode/Cursor and want to be able to access it while writing notebook code.

Colab only lets you connect to compute provided by Google. For instance, even Colab Pro doesn't offer H100s, whereas you can get that pretty easily on Runpod.