Maybe it’s just two different ways to reach the same result. You need to spend time to be great at prompting to get high-quality code from LLM’s, which might just be equivalent to the fact you need to spend time to write high-quality code without LLM’s too.

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.

DB does not decide how much to invest in infrastructure, that’s decided by politicians.

Politicians do not dictate operational decisions. If they allocate X for infrastructure, the company should scale up or scale down to match that budget, rather than overpromise.

”The company” is not one company. The infrastructure manager (DB InfraGo in Germany) is managing tracks on behalf of the state. Operators (a regional operator in the case of this article) run as many trains as they want/are allowed, which in practice is more than the system can handle reliably. There are laws regulating how track access is awarded, so even when a DB group operator runs on tracks managed by DB InfraGo there is no single ”company” that makes a certain promise. The remedy is political either way, either change how track access is awarded to limit the number of trains allowed or increase funding for added capacity and maintenance.

As I see it, InfraGo could technically fix the problem by increasing operational buffers based on failure rates and reduce number of slots. This would contain the cascade of delays, but they decide to go easy way because they are not accountable for those delays. So in principle you are right, it’s a political problem - cost of delays is not shared with infrastructure provider as it should be, and while InfraGo actually could fix the problem (because they determine the number of slots), they choose not to.

The main issue is over-utilisation and under-investment of the rail network. Like in many other EU countries. There is no evidence that a state monopoly would perform any better given today’s state of infrastructure and increased traveler numbers.

The under-investment stems from the neoliberal idea that it should be run at a profit and that competition will make everything super efficient.

The under-investment is predominantly in infrastructure, which is owned by states or regions and not under any competition.

And this under-investment stems from the neoliberal idea that transport should run at a profit rather than be treated as a service that has a cost.

Competition on the railways is mandated through EU law.

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.

Love the application and visualization!

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.

Isn't this what the last part of TFA covers?

There might be parallells with group development research or terms used, but neither Tuckman’s stages, the research it’s based on, or later research in the area apply outside of the internal dynamics of individual working groups.

Runtime access, yes. But I’m assuming this is to also prevent cookie/storage sharing between PWA:s too, which third party browser vendors (well, Google) have incentive to allow and Apple wants to prevent.

Last I calculated this, a new car emits in the range of 8-15 tonnes CO2e (lower range for gas cars, upper for some EVs before they started guaranteeing renewable energy in production).

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.

Yes, but not everyone drives an average amount. I drive about a third of that.

On the other hand I also know people who drive a multiple of that.

Building is a very expensive way of finding user needs, especially since you might rely on luck to start out even in the right ballpark.

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.

This is how it works in my country (Sweden). Everything that provides any sort of personal benefit to an employee is taxed as ”benefit tax” which simply increases the taxable income. Very few exceptions exist for small yearly gifts, health benefits and a few other things.