Frontier LLMs write better code at CRUD tasks than 95% of developers today. They’ll get to 95% of most niche coding domains by December and likely all coding tasks sometime next year; 99% better at all tasks by December 2028.
You may be correct now and it doesn’t matter one bit.
We’ve been hearing the drumbeat that these models are already better than $INVENT_A_NUMBER percentage of developers at $SOME_SMALL_TASK for several years. I haven’t seen that it’s actually true yet personally.
What I do see is that the frontier models can get easy stuff mostly right, but they can’t maintain a small codebase such that it behaves correctly across several mutations. When the going requires a lot of context, tests get rewritten to not do anything and features that manipulate similar data get divergent implementations. That’s fine for goofing around personally, but I see vibe coders getting their asses handed to them when they mistake that for a well maintained codebase and try to sell a product.
Please, don’t mistake an impressive technology for a miracle; there will still be people needed to make codebases healthy for a long time to come.
This reads like it can write a better javascript function that executes a SQL statement and maps the parameters.
> They’ll get to 95% of most niche coding domains by December and likely all coding tasks sometime next year; 99% better at all tasks by December 2028.
Basing this prediction on LLMs writing what something like an ORM would generate for you doesn't connect for me.
I'd say as long as we can clearly see the 5% are working better than an LLM, why not strive for it? Shows what humans are capable of, and it's probably achievable to most.
I'm not hanging my hat yet and can still see where LLMs struggle. I think it's the best bet you can make: keep working for the future where you'll still be needed, because you can't prepare for the future where you're not.
I agree about your general assessment, but I don't see my coding skills of, depending on how you count them two or three decades, being needed in 36 months - so I'm trying to upskill LLM piloting, but that also seems a bit of a dead end since LLMs will be perfectly capable of piloting themselves in approximately the same timeframe - we'll see what needs upskilling in by winter...
End-goal seems like making money in this line of thinking so I recommend spinning up some gambling racket or getting into finance, you don't need to program anyways.
This is specifically what people pumping these ideas are doing as you can see like Sam Altman or Dario.
I think there are far more people who can't write better code than an LLM. Of course, there are a few exceptions, but it's a fact that LLMs are already handling PhD-level mathematics and papers.
I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions. As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research. The vast majority of people don't have that level of education. Of course, having a PhD doesn't guarantee good coding, but at least it's clear that LLMs can handle that level of capability.
People might disagree, but my view is firm on this.
> I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions.
Remember that the quality of the LLMs code in the areas you don’t know is as good as the quality as the area you do know. You’re only able to gauge the quality of what you do know.
Your main target seems to be the view that software quality is a matter of 'aesthetic intuition,' but I see it differently. I think because it's 'engineering,' there must be measurable indicators.
Executable specifications
Unit, integration, and property tests
Official API documentation
All of these provide ways to judge quality. There are so many metrics that the problem is actually choosing which ones to use.
1.Does it produce output A for input B?
2.Can it process 100,000 records within 5ms?
3.Is memory usage within the defined limit?
4.Does the protocol handle error conditions properly?
You don't need to be an expert to test these. People forget that programming is one of the few fields where judgment criteria can be easily translated into machine executable tests.
The biggest problem with epistemological objections is that they often assume a binary: 'experts can judge, non-experts cannot.' But in reality, it's a continuous process.
You run the code, notice something odd, look up the terminology, compare it with official documentation and reference implementations, add tests, and gradually build up judgment in that area. Rewriting LLM generated code compresses that entire learning curve.
In the past, entering an unfamiliar domain meant starting from a blank file and reading documentation. Now, you start with a working hypothesis and modify it. That's far cheaper than starting from scratch.
If you treat LLM generated code as executable teaching material and a falsifiable hypothesis, it's a very powerful resource.
I feel uncomfortable when people reduce programming to aesthetic quality alone. We were all trained to measure things.
My "aesthetic" sense is more about how modular the code is, how DRY (which is also an aesthetic balancing act), how clean the abstractions are and how well they fit the domain and the workflow.
Also, error handling.
Tests, specs, and docs are are all downstream of that.
So far I've found that AI does an adequate-to-very-good job up to a certain amount of code, then things tend to fall apart. The solution is modularity and clean interfaces - as it always was.
I'm not really sure. I'm mostly thrown into existing codebases and just modify things to fit the existing style, so I'm almost always evaluated purely by metrics. I do think your (TheOtherHobbes) standards are really good, though.
>You’re only able to gauge the quality of what you do know.
That's not true. You can follow the logic step by step, search for similar domains, and form a comparison group.
Realistically, if we take this logic to its conclusion, it's like asking: 'You're just a spectator, so can you really judge whether a football player is good at football?
Realistically, LLMs write code well. I'm a C# programmer, and as you know, the current trend in modern programming is to refine error handling—using try/catch at higher layers, working with monads, preserving computable contexts, and branching accordingly. That kind of code typically takes 1 to 2 hours of modeling before you even start writing.
But an LLM can do it in just 5 minutes.
So I think the opposite way: if LLMs can do this well in a domain I'm familiar with, they're probably just as capable in other domains too. And that makes them feel trustworthy.
And more importantly, no matter how great a human programmer is, once you step outside your domain, you're in unknown territory. In those areas, LLMs are surprisingly helpful.
Epistemologically, it might be true that you can't evaluate code in a domain you don't know. But people keep forgetting the fact that you can learn through that code. This very post is itself an example of learning through LLM-typed code.
And programming actually provides clearer results than many other domains. It's not based on subjective UX like UI design. You have:
1.Executable specifications
2.Performance measurements
3.Comparisons with official documentation
These are clear engineering outcomes that allow for objective comparison. For example, you can verify whether a program produces results within 5ms when executed.
Many epistemological arguments tend to overlook this.
A lot of code is open source. You can find mature implementations anywhere. Finding a repo from someone claiming 10 or 20 years of experience and running a differential comparison is not difficult at all."
I've had opportunities to look at code from Korean and Chinese companies, not just academia. From what I've seen, AI generated code is often better than the average code in those codebases.
When I talk about PhD level code, I'm not referring to research code quality. I'm talking about research level algorithms.
Production code is built around reusability, policies, monadic chaining, and various code hygiene practices. Research code isn't. So what I'm saying is: 'Yes, I've collaborated with professors from top Korean universities.'
That said, I'm not writing PhD level code myself. The reason is that I take existing algorithms and apply code hygiene to them. I'm not actually developing new algorithms at a PhD level of understanding
So from what you're saying, it sounds like:
'Are you talking about those horrible research paper codes?'
But what exists in those research papers is:
'The domain modeling itself is difficult.'
I learned about code hygiene in production code—things like using functional approaches, and so on. Research code often lacks those things, so it might look bad. But that means the code quality is bad—not that the modeling itself is bad. And in fact, the core value is in being able to produce modeling at that level of difficulty.
In fact, most programmers, if trained like me, can do these things well enough. But domain modeling is different.
This touches on the distinction Frederick Brooks made in The Mythical Man-Month between 'Essential Complexity' and 'Accidental Complexity.' Code hygiene, functional chaining, monadic structures—these are techniques for reducing accidental complexity. With enough training, you can learn them. But domain modeling deals with essential complexity. It's about how difficult the problem itself is, and it's not easily solved through training alone. That's why the depth of modeling that researchers produce should be evaluated on a different axis from code quality.
This is what we call 'Essential Complexity.' From that perspective, saying code is 'good' usually means that the essential complexity is handled well on average. What I'm calling 'PhD-level' usually refers to modeling problems that are commonly difficult to solve.
I see it 'very often.' Most research paper code has no reusability—they just implement the algorithm.
So I can see why it might be considered low-quality. They don't use things like Result or policy types like we do in production code. But they're modifying or creating new algorithms, right?
The thing is, they don't need to do those things, so it looks lower-level—but the algorithm implementations themselves are actually pretty good, aren't they?
PhD thesis code often looks low-quality simply because there's no reason to reuse it like production code. The tensor computations inside are things that typical programmers can't easily do.
The point I'm making is that the core algorithmic work is something most programmers can't handle. And that's natural—highly skilled programmers have already built deep libraries for that.
When I talk about PhD-level code, I'm not referring to overall code quality. I'm talking about the level of the algorithms themselves.
> there's no reason to reuse it like production code.
This strikes me as a self-fulfilling prophecy. There are probably many people who would like to use the code published with PhD level research, but they don't because the code is not easy to adapt (or sometimes even to get running).
Then a decade later someone implements that same algorithm in a library with a well-designed interface and it suddenly becomes a useful tool for others. So ultimately there was a reason to reuse it, it was the quality of some aspects of the code that held it back.
Frontier LLMs write better code at CRUD tasks than 95% of developers today. They’ll get to 95% of most niche coding domains by December and likely all coding tasks sometime next year; 99% better at all tasks by December 2028.
You may be correct now and it doesn’t matter one bit.
We’ve been hearing the drumbeat that these models are already better than $INVENT_A_NUMBER percentage of developers at $SOME_SMALL_TASK for several years. I haven’t seen that it’s actually true yet personally.
What I do see is that the frontier models can get easy stuff mostly right, but they can’t maintain a small codebase such that it behaves correctly across several mutations. When the going requires a lot of context, tests get rewritten to not do anything and features that manipulate similar data get divergent implementations. That’s fine for goofing around personally, but I see vibe coders getting their asses handed to them when they mistake that for a well maintained codebase and try to sell a product.
Please, don’t mistake an impressive technology for a miracle; there will still be people needed to make codebases healthy for a long time to come.
> write better code at CRUD tasks
This reads like it can write a better javascript function that executes a SQL statement and maps the parameters.
> They’ll get to 95% of most niche coding domains by December and likely all coding tasks sometime next year; 99% better at all tasks by December 2028.
Basing this prediction on LLMs writing what something like an ORM would generate for you doesn't connect for me.
I'd say as long as we can clearly see the 5% are working better than an LLM, why not strive for it? Shows what humans are capable of, and it's probably achievable to most.
I'm not hanging my hat yet and can still see where LLMs struggle. I think it's the best bet you can make: keep working for the future where you'll still be needed, because you can't prepare for the future where you're not.
I agree about your general assessment, but I don't see my coding skills of, depending on how you count them two or three decades, being needed in 36 months - so I'm trying to upskill LLM piloting, but that also seems a bit of a dead end since LLMs will be perfectly capable of piloting themselves in approximately the same timeframe - we'll see what needs upskilling in by winter...
How this presents, however, I would think, is that being that top 5% and utilizing LLMs will get you further than either alone.
I think that's a reasonable view. Though I personally see LLMs more as replacers, not as tools to utilize.
You are cooked if you think the end goal was the quality of the code and not the quality of the product.
End-goal seems like making money in this line of thinking so I recommend spinning up some gambling racket or getting into finance, you don't need to program anyways.
This is specifically what people pumping these ideas are doing as you can see like Sam Altman or Dario.
You won't get a quality product built on sloppy code.
Absolutely delusional if you think the two aren't related
What is "better code"?
I think there are far more people who can't write better code than an LLM. Of course, there are a few exceptions, but it's a fact that LLMs are already handling PhD-level mathematics and papers.
I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions. As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research. The vast majority of people don't have that level of education. Of course, having a PhD doesn't guarantee good coding, but at least it's clear that LLMs can handle that level of capability.
People might disagree, but my view is firm on this.
> I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions.
Remember that the quality of the LLMs code in the areas you don’t know is as good as the quality as the area you do know. You’re only able to gauge the quality of what you do know.
Your main target seems to be the view that software quality is a matter of 'aesthetic intuition,' but I see it differently. I think because it's 'engineering,' there must be measurable indicators.
Executable specifications
Unit, integration, and property tests
Official API documentation
All of these provide ways to judge quality. There are so many metrics that the problem is actually choosing which ones to use.
1.Does it produce output A for input B? 2.Can it process 100,000 records within 5ms? 3.Is memory usage within the defined limit? 4.Does the protocol handle error conditions properly?
You don't need to be an expert to test these. People forget that programming is one of the few fields where judgment criteria can be easily translated into machine executable tests.
The biggest problem with epistemological objections is that they often assume a binary: 'experts can judge, non-experts cannot.' But in reality, it's a continuous process.
You run the code, notice something odd, look up the terminology, compare it with official documentation and reference implementations, add tests, and gradually build up judgment in that area. Rewriting LLM generated code compresses that entire learning curve.
In the past, entering an unfamiliar domain meant starting from a blank file and reading documentation. Now, you start with a working hypothesis and modify it. That's far cheaper than starting from scratch.
If you treat LLM generated code as executable teaching material and a falsifiable hypothesis, it's a very powerful resource.
I feel uncomfortable when people reduce programming to aesthetic quality alone. We were all trained to measure things.
My "aesthetic" sense is more about how modular the code is, how DRY (which is also an aesthetic balancing act), how clean the abstractions are and how well they fit the domain and the workflow.
Also, error handling.
Tests, specs, and docs are are all downstream of that.
So far I've found that AI does an adequate-to-very-good job up to a certain amount of code, then things tend to fall apart. The solution is modularity and clean interfaces - as it always was.
I'm not really sure. I'm mostly thrown into existing codebases and just modify things to fit the existing style, so I'm almost always evaluated purely by metrics. I do think your (TheOtherHobbes) standards are really good, though.
>You’re only able to gauge the quality of what you do know.
That's not true. You can follow the logic step by step, search for similar domains, and form a comparison group.
Realistically, if we take this logic to its conclusion, it's like asking: 'You're just a spectator, so can you really judge whether a football player is good at football?
Realistically, LLMs write code well. I'm a C# programmer, and as you know, the current trend in modern programming is to refine error handling—using try/catch at higher layers, working with monads, preserving computable contexts, and branching accordingly. That kind of code typically takes 1 to 2 hours of modeling before you even start writing.
But an LLM can do it in just 5 minutes.
So I think the opposite way: if LLMs can do this well in a domain I'm familiar with, they're probably just as capable in other domains too. And that makes them feel trustworthy.
And more importantly, no matter how great a human programmer is, once you step outside your domain, you're in unknown territory. In those areas, LLMs are surprisingly helpful.
Epistemologically, it might be true that you can't evaluate code in a domain you don't know. But people keep forgetting the fact that you can learn through that code. This very post is itself an example of learning through LLM-typed code.
And programming actually provides clearer results than many other domains. It's not based on subjective UX like UI design. You have:
1.Executable specifications
2.Performance measurements
3.Comparisons with official documentation
These are clear engineering outcomes that allow for objective comparison. For example, you can verify whether a program produces results within 5ms when executed.
Many epistemological arguments tend to overlook this.
A lot of code is open source. You can find mature implementations anywhere. Finding a repo from someone claiming 10 or 20 years of experience and running a differential comparison is not difficult at all."
> As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research.
This gave me a chuckle, "PhD-level code" is gross actually. Have you ever looked at the code of research papers?
I've had opportunities to look at code from Korean and Chinese companies, not just academia. From what I've seen, AI generated code is often better than the average code in those codebases.
When I talk about PhD level code, I'm not referring to research code quality. I'm talking about research level algorithms.
Production code is built around reusability, policies, monadic chaining, and various code hygiene practices. Research code isn't. So what I'm saying is: 'Yes, I've collaborated with professors from top Korean universities.'
That said, I'm not writing PhD level code myself. The reason is that I take existing algorithms and apply code hygiene to them. I'm not actually developing new algorithms at a PhD level of understanding
So from what you're saying, it sounds like:
'Are you talking about those horrible research paper codes?'
But what exists in those research papers is: 'The domain modeling itself is difficult.'
I learned about code hygiene in production code—things like using functional approaches, and so on. Research code often lacks those things, so it might look bad. But that means the code quality is bad—not that the modeling itself is bad. And in fact, the core value is in being able to produce modeling at that level of difficulty.
In fact, most programmers, if trained like me, can do these things well enough. But domain modeling is different.
This touches on the distinction Frederick Brooks made in The Mythical Man-Month between 'Essential Complexity' and 'Accidental Complexity.' Code hygiene, functional chaining, monadic structures—these are techniques for reducing accidental complexity. With enough training, you can learn them. But domain modeling deals with essential complexity. It's about how difficult the problem itself is, and it's not easily solved through training alone. That's why the depth of modeling that researchers produce should be evaluated on a different axis from code quality.
This is what we call 'Essential Complexity.' From that perspective, saying code is 'good' usually means that the essential complexity is handled well on average. What I'm calling 'PhD-level' usually refers to modeling problems that are commonly difficult to solve.
I see it 'very often.' Most research paper code has no reusability—they just implement the algorithm.
So I can see why it might be considered low-quality. They don't use things like Result or policy types like we do in production code. But they're modifying or creating new algorithms, right?
The thing is, they don't need to do those things, so it looks lower-level—but the algorithm implementations themselves are actually pretty good, aren't they?
PhD thesis code often looks low-quality simply because there's no reason to reuse it like production code. The tensor computations inside are things that typical programmers can't easily do.
The point I'm making is that the core algorithmic work is something most programmers can't handle. And that's natural—highly skilled programmers have already built deep libraries for that.
When I talk about PhD-level code, I'm not referring to overall code quality. I'm talking about the level of the algorithms themselves.
> there's no reason to reuse it like production code.
This strikes me as a self-fulfilling prophecy. There are probably many people who would like to use the code published with PhD level research, but they don't because the code is not easy to adapt (or sometimes even to get running).
Then a decade later someone implements that same algorithm in a library with a well-designed interface and it suddenly becomes a useful tool for others. So ultimately there was a reason to reuse it, it was the quality of some aspects of the code that held it back.