[reconnecting]

Did you also notice the evolution of average developers over time? I mean, if you take code from a developer ten years ago and compare it with their output now, you can see improvement.

I assume that over time, the output improves because of the effort and time the developer invests in themselves. However, LLMs might reduce that effort to zero — we just don't know how developers will look after ten years of using LLMs now.

Still, if you have 30 years of experience in the industry, you should be able to imagine what the real output might be.

[vidarh]

> Did you also notice the evolution of average developers over time? I mean, if you take code from a developer ten years ago and compare it with their output now, you can see improvement.

This makes little sense to me. Yes, individual developers gets better. I've seen little to no evidence that the average developer has gotten better.

> However, LLMs might reduce that effort to zero — we just don't know how developers will look after ten years of using LLMs now.

It might reduce that effort to zero from the same people who have always invested the bare minimum of effort to hold down a job. Most of them don't advance today either, and most of them will deliver vastly better results if they lean heavily on LLMs. On the high end, what I see experienced developers do with LLMs involves a whole lot of learning, and will continue to involve a whole lot of learning for many years, just like with any other tool.

[reconnecting]

After 30 years in front of the desktop, we are processing dopamine differently.

When I speak about 10 years from now, I’m referring to who will become an average developer if we replace the real coding experience learning curve with LLMs from day one.

I also hear a lot of tool analogies — tractors for developers, etc. But every tool, without an exception, provides replicable results. In the case of LLMs, however, repeatable results are highly questionable, so it seems premature to me to treat LLMs in the same way as any other tool.

[Terr_]

Right, I've seen a lot of facile comparisons to calculators.

It may be true that a cohort of teachers were wrong (on more than one level) when they chastised students with "you need to learn this because you won't always have a calculator"... However calculators have some essential qualities which LLM's don't, and if calculators lacked those qualities we wouldn't be using them the way we do.

In particular, being able to trust (and verify) that it'll do a well-defined, predictable, and repeatable task that can be wrapped into a strong abstraction.

[vidarh]

> if we replace the real coding experience learning curve with LLMs from day one.

People will learn different things. They will still learn. Most developers I've hired over the years do not know assembly. Many do not know a low-level language like C. That is a downside if they need to write assembly, but most of them never do (and incidentally, Opus knows x86 assembly better than me, knows gdb better than me; it's still not good at writing large assembly programs). It does not make them worse developers in most respects, and by the time they have 30 years experience the things they learn instead will likely be far more useful than many of the things I've spent years learning.

> But every tool, without an exception, provides replicable results.

This is just sheer nonsense, and if you genuinely believe this, it suggests to me a lack of exposure to the real world.

[reconnecting]

My point is not what is learned but how. Debugging, reading errors, understanding how things put together — that is the learning.

You haven't replaced assembler with C here, you've replaced programming with Scrabble.

[ekrisza]

> However, LLMs might reduce that effort to zero — we just don't know how developers will look after ten years of using LLMs now.

LLMs might help the new joiner produce code on the level of an average developer faster. But, at the same time, if LLMs are really trained on all open source repositories without any selection, that level might be limited.

I have recently published a potentially related article: https://link.springer.com/article/10.1007/s44427-025-00019-y

It looks like the overwhelming majority of projects on Github, does not really follow stable growth tendencies. In all fairness, as these were the smaller projects, their developers might have never intended to demonstrate best practices, or make the project sustainable on the long-term.

This is all fine, experimentation and learning are very welcome in open source. But, with 83,9% of the projects (in my study) falling into this category, LLM might pick them up as demonstrating overwhelmingly popular best practices. In the worst case, this might even lead to actual best practices being drowned out, over time.

[znort_]

> if you take code from a developer ten years ago and compare it with their output now, you can see improvement.

really? it depends on the type of development, but ten years ago the coder profession had already long gone mainstream and massified, with a lot of people just attracted by a convenient career rather than vocation. mediocrity was already the baseline ("agile" mentality to at the very least cope with that mediocrity and turnover churn was already at its peak) and on the other extreme coder narcissism was already en vogue.

the tools, resources, environments have indoubtedly improved a lot, though at the cost of overhead, overcomplexity. higher abstraction levels help but promote detachment from the fundamentals.

so specific areas and high end teams have probably improved, but i'd say average code quality has actually diminished, and keeps doing so. if it weren't for qa, monitoring, auditing and mitigation processes it would by now be catastrophic. cue in agents and vibe coding ...

as an old school coder that nowadays only codes for fun i see llm tools as an incredibly interesting and game changing tool for the profane, but that a professional coder might cede control to an agent (as opposed to use it for prospection or menial work) makes me already cringe, and i'm unable to wrap my head around vibe coding.