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.

Sure - and I suspect we will see that soon enough. But it has downsides too, and finding the right way to vet potential contributors is tricky.

Even if we assume that LLMs become good enough for this to be true (some might feel that is the case already - I disagree, but that is beside the point), there is no reason why OSS maintainers should accept such outside contributions that they would need to carefully review, as it comes from an untrusted source, when they could just use the tools themselves directly. Low effort drive-by PRs is a burden with no upside.

The problem is the increasing review burden - with LLMs it is possible to create superficially valid looking (but potentially incorrect) code without much effort, which will still take a lot of effort to review. So outright rejecting code that can identified as LLM-generated at a glance, is a rough filter to remove the lowest effort PRs.

Over time this might not be enough, though, so I suspect we will see default deny policies popping up soon enough.

Not necessarily a bad idea, but I think the bigger issue here and now is the increasing assymmetry in effort between code submitter and reviewer, and the unsustainable review burden on the maintainers if nothing is done.

I suspect this is for now just a rough filter to remove the lowest effort PRs. It likely will not be enough for long, though, so I suspect we will see default deny policies soon enough, and various different approaches to screening potential contributors.

I think this is a reasonable decision (although maybe increasingly insufficient).

It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers.

In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly generate PRs that might look superficially correct. Effort can still have been out into those PRs, but there is no way to tell without spending time reviewing in more detail.

Policies like this help decrease that review burden, by outright rejecting what can be identified as LLM-generated code at a glance. That is probably a fair bit today, but it might get harder over time, though, so I suspect eventually we will see a shift towards more trust-based models, where you cannot submit PRs if you haven't been approved in advance somehow.

Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.

Correct, but that has and probably always will be the case.

You spend the time on what is needed for you to move ahead - if code review is now the most time consuming part, that is where you will spend your time. If ever that is no longer a problem, defining requirements will maybe be the next bottleneck and where you spend your time, and so forth.

Of course it would be great to get rid of the review bottleneck as well, but I at least don't have an answer to that - I don't think the current generation of LLMs are good enough to allow us bypassing that step.

I of course cannot say what the future holds, but current frontier models are - in my experience - nowhere near good enough for such autonomy.

Even with other agents reviewing the code, good test coverage, etc., both smaller - and every now and then larger - mistakes make their way through, and the existence of such mistakes in the codebase tend to accellerate even more of them.

It for sure depends on many factors, but I have seen enough to feel confident that we are not there yet.

If reviewing has become the bottleneck, the obvious - albeit slightly boring - solution is to slow down spitting out new code, and spend relatively more time reviewing.

Just going ahead and piling up PRs or skipping the review process is of course not recommended.

You can use this: [email protected]

I don't expect that - am merely responding to the parent comments claim that Claude consistently one-shots production ready code (which does not at all match my observations).

Feel free to share it, would be very curious - ideally alongside the prompts.

I have used Claude (incl. Opus 4.6) fairly extensively, and Claude still spits out quality that is far below what I would call production ready - both littered with smaller issues, but also the occasional larger blunder. Particularly when doing anything non-trivial, and even when guiding it in detail (although that admittedly reduces the amount of larger structural issues).

Maybe it is tech stack dependent (I have mostly used it with C#/.NET), but I have heard people say the same for C#. The only conclusion I have been able to draw from this, is that people have very different definitions of production ready, but I would really like to see some concrete evidence where Claude one-shots a larger/complex C# feature or the like (with or without detailed guidance).

There are some really baffling takes here. And it doesn't really matter how good or bad coding agents are.

Coding agents greatly reduce the barrier to contributing something that at least looks okay at the surface, so reviewing contributions will quickly become even more of a bottleneck. Manual contributions used to filter away most low effort attempts, or at least they could easily be identified and rejected.

That dynamic is now different and the maintainers risk being swarmed with low effort contributions, that will take a lot of time to review and respond to. Some AI contributions might be reviewed and revised and overall be of acceptable quality, but how can the maintainers know which without reviewing everything, good and bad alike.

I think we will see multiple attempts like this to shift things back to the old dynamic, by rejecting things that can be identified as AI generated a glance, but I suspect over time it will be difficult to do so, so my prediction is that we will soon see more open source repos stop accepting outside contributions entirely.

Even if LLMs one day will be good enough to quickly produce code that is on par with humans (which I strongly doubt), why would the contributors have any incentive to have someone else do that (the easy part), rather than just doing it themselves?

This article seems completely out of line with reality, maybe I am living on a different planet.

I have never heard of anyone following those SDLC steps rigorously and sequentially. Things tend to be much more intertwined, combined, and iterative than this suggests.

Even if agents were writing the code, someone would still need to identify what actually needs to be done - requirements don'y magically pop out of nowhere.

He doesn't know a single person(!?) still writing code by hand? Even the most hardcore believers in coding agents that I know still review and revise code by hand. Even the sota models spit out garbage if not carefully guided and reviewed (and even then quality is still behind an experienced human engineer for anything non-trivial).

This all seems so far from the reality I live in...