Comment by nolist_policy

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.