ptnpzwqd

Juggling multiple e-mail accounts in a single client, and I haven't found anything better - also haven't really had any major complaints, the desktoo app works perfectly for what I use it for.

What alternative do you suggest?

Yes, but Sweden and Denmark have been very different in their approach to personal numbers, and a lot of us here in DK are looking at the Swedish model as an example of how this _should_ work.

I am not sure what evidence you are looking for, but I have myself picked up prescription medicine using nothing but my CPR number on multiple occasions, including picking it up on behalf of my wife (providing just her CPR number and name).

I think you mean that isn’t how they are meant to be used. If that was consistently the case in practice, however, no one would talk about this leak (at least not the CPR number part of it).

I doubt the CPR number alone will give you access to obtain credit and the like today, but you can absolutely go into a pharmacy and buy someone’s prescription medicine with just their CPR number, and you for sure can get access to a lot of data by calling various entities and providing your CPR number as proof of identity (but at least fewer now than used to be the case in the past).

If the CPR number was truly made public information, those cases would be much more obviously wrong. The fact that CPR numbers are de facto considered pseudo-secret makes things much worse.

It is easy to blame the company or individual responsible for making the leak possible, and of course also well justified, but I think the bigger problem is the way the CPR number is used.

Having a unique number that is needed for identifying individuals, but also often used for authentication and thus meant to be kept secret, is bound to go wrong. There are too many situations where these use cases are in conflict, and considering Denmark has MitID - a actual national authentication solution - the CPR number should have been considered public information a long time ago, and shouldn’t ever be usable for obtaining credit or the like on its own. A system keeps insisting this is sensitive information is really the main responsible here.

Be that as it may, it would seem absurd if we start calling distillation out as antagonistic, but don't do the same for the SOTA models being trained on human-created data.

This does not really match my observations. While it does feel to me the sentiment is shifting towards a more negative one, overall HN feels reasonably balanced between those that are pro-AI and those anti-AI (with the middle ground somewhat absent).

Unlike what many other comments here seem to suggest, HN seems much more pro-AI than what I see in real life amongst developers - at least where I live.

And I do think many users would care more than we might think, but unlike art etc. it is often more difficult to tell.

Responses seem to be very "either or" as usual on such topics.

I think it should be possible to appreciate how impressive this is on one hand, while also discussing the limitations of the approach.

Everyone can probably agree that getting this far without LLMs would have taken substantially longer and required a huge amount of work.

But what is then the end result?

Personally, for me it would still be hard pass on using a 1M LoC LLM-migrated language runtime - I have seen CC do enough crazy things to still be wary of any code without a human in the loop. It simply plays too fundamental a role in the tech stack. Others might feel differently, and time will tell how things play out.

Even if this does play out as optimistically as one can imagine, would it then mean I can go and migrate some of my enterprise codebases the same way? I doubt it.

Bun has the nice feature that it has an extensive set of black box / E2E tests that don't themselves need migrating. Most projects in the wild seem to be much more reliant on unit and integration tests that are part of the codebase itself, and would therefore also need to be migrated and be subject to mistakes in the migration process.

It also seems fairly rare that test suites are good enough to guarantee that the program will work as expected in all cases. I am yet to come across a larger enterprise codebase where the tests were good enough to make human review and even manual testing fully redundant. To be honest I doubt that is the case for Bun either, but I don't know enough about bun to conclude that.

I think a notable difference is that the AI that is portrayed in most sci-fi (that I have read/watched anyway) tend to be "logical machines" that act deterministically based on the data available to them.

What we got are "statistical machines" that tend to do the right thing under the right conditions, but can go completely off the rail every now and then.

The former are more akin to a generalization of computers as we typically think of it, whereas the latter is something else. Maybe that something else is closer to human behavior in some ways, but also so very different - unlike humans, where you get to know people, build relationships, know who to trust in what ways, and so forth, you can never really trust an LLM with any critical tasks without close supervision.

I feel the conclusions here are a bit thin.

Code quality tends to have an impact on more than just aesthetics - and Claude Code certainly feels like a buggy mess from an end user's perspective.

Of course people still use Claude Code, but that is certainly because of the underlying models first and foremost. Most products don't have such a moat and would not nearly see as much tolerance from end users. If the Max subscriptions could be used with other harnesses, I am sure Anthropic would have to compete harder on the quality of the harness (to be fair, most AI based tooling seems pretty alpha these days, but eventually things will stabilize).

Polish is not everything, clearly, but it is a factor, and I feel Claude Code is maybe the worst example to use here, as it doesn't at all generalize to most other products.

On the falling behind:

I strongly doubt that is going to be the case - picking up these tools is not rocket science, even if you want to be able to use them fairly effectively. In addition, there is so much churn in AI tooling these days that an early investment might not really be worth a lot in the longer run.

On the other hand, hands-on experience in programming and architecture is currently a must-have to use the tools effectively - and continuing without AI in the short term might just buy an inexperienced engineer some time to learn, and postpone skill atrophy for an experienced engineer.

Of course, who can know what the future looks like, but I doubt a "wait and see" approach is that dangerous to anyone's career.

I live in two realities too.

One where articles like this talk about a 10x increase in productivity, where the sentiment on HN is that all software can now be vibe coded without review, where AGI is right around the corner.

And another reality where we don't really see any measurable difference in productivity betweens that have gone all in on LLMs and those that haven't, where the current SOTA models still produce bad quality that needs a lot of guidance and revision, where mediocre engineers that never cared about quality in the first place now use these tools to produce even more mediocre code, where the most talented engineers get bogged down reviewing low quality LLM-generated PRs, and so on.

Maybe a bit exaggerated, but OP definitely lives in a very different reality from the one I am seeing. So different that I find it extremely hard to believe.

It was maybe not quite clear enough in my comment, but this is more of a hypothetical future scenario - not at all where I assess LLMs are today or will get to in the foreseable future.

So it becomes a bit theoretical, but I guess if we had a future where LLMs could consistently write perfect code, it would not be too far fetched to also think it could perfectly review code, true enough. But either way the maintainer would still spend some time ensuring a contribution aligns with their vision and so forth, and there would still be close to zero incentive to allow outside contributors in that scenario. No matter what, that scenario is a bit of a fairytale at this point.

Yes, but LLM-based reviews are not nearly a compensation for human review, so it doesn't change much.

Yes, I agree. It was just me playing with a hypothetical (but in my view not imminent) future where vibe-coding without review would somehow be good enough.

At the moment verification at scale is an unsolved problem, though. As mentioned, I think this will act as a rough filter for now, but probably not work forever - and denying contributions from non-vetted contributors will likely end up being the new default.

Once outside contributions are rejected by default, the maintainers can of course choose whether or not to use LLMs or not.

I do think that it is a misconception that OSS software needs to "viable". OSS maintainers can have many motivations to build something, and just shipping a product might not be at the top of that list at all, and they certainly don't have that obligation. Personally, I use OSS as a way to build and design software with a level of gold plating that is not possible in most work settings, for the feeling that _I_ built something, and the pure joy of coding - using LLMs to write code would work directly against those goals. Whether LLMs are essential in more competitive environments is also something that there are mixed opinions on, but in those cases being dogmatic is certainly more risky.