From where I’m standing, I don’t see any massive difference on overall productivity between anyone all in on vibe coding than those who aren’t. There’s not more features, higher quality, etc from teams/companies out there than before on any high-level metrics/observations. Maybe it will come, but there’s also no evidence it will.

I do, however, see great gains within certain specific tasks using LLM’s. Smaller scope code gen, rubber ducking, etc. But this seems much less difficult to get good at using (and I hope for tooling that help facilitate the specific types of use cases) and on the whole amounts to marginal gains. It seems fine to be a few years late to catch up, worst case.

Most regional services are tendered to the (in theory) best operator. The details on how, both which governing body organises the tender and whether the trains are branded by the region or the operator, varies across Europe. In Germany, these contracts are operated by a mix of DB, foreign state-owned operators and private operators. DB sells tickets for all region-organised trains regardless of who is the current operator.

Most countries have decided to have no or limited tenders on long-distance trains. In Germany, government support is prohibited for long-distance.

Having spent the past year building a journey planner algorithm, which heavily builds on pareto optimality/sets, from scratch, I was waiting for the full set of pareto optimal solutions. I.e. all kart combinstions that are best in at least one way.

Should be doable by iterating through all possible stats and merging[1] into a set for each one. We might get a lot of solutions, but it should be somewhat managable.

Has anyone tried this?

1: Merging is to take the new entry and 1) removing any existing entry that is dominated by it, and 2) adding the entry if it is not dominated by any existing entry.

Driving emissions numbers I remember off the top of my head are Swedish averages, around 2.5 tonnes CO2e per year (15000 km/year). This is averages for the Swedish car fleet, which tend to be smaller models and more modern than many countries.

So: sure, production emissions are a big factor, but driving the car can easily win the efficiency savings back in a fraction of the car’s lifetime.

I think of innovative products as the combination of a user need insight and an innovative solution. I think there’s a lot of time wasted when teams focus too much on iterating on one without the other.

If you’re a technologist who sees the potential in a particular technology, you need to start by thinking about how to navigate towards applying it to a real user need. The flipside happens too, where a team sees a need and gets stuck in circles because they lack the tech expertise to build a solution that delivers & is competitive (but surely less commonly in the HN crowd).

Someone good at one of these things but less interested in the other should find a co-founder who’s good at the other perspective.

To me, this clearly should be considered a breaking change, which I normally would expect to look out for when the major version number changes. I get that checking module definitions means unchanged code won’t break, but it might break code in ways I as a programmer would not expect when upgrading minor versions. It might be technically correct according to some definition, but lacks practicality, which has been a recurring feeling for me as I get into the language.

For styles that are reused a lot I just create small & composable components (which are also defined by the Tailwind classes so they match distances & colors). But there are typically just a handful of these in a project.