Hacker News Reader

Comment by arcadialeak | Hacker News Reader

It's quite frightening to see how an enormous 120KLOC pull request gets merged at once with very little public discussion or coverage by the devs after just 3 months (which IMO is very little time in relation to the amount of code). There used to be extensive RFCs and series of conference talks long preceding changes this big, e.g. React Fiber.

I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.

View on HN

Seems like all the "best practices" that were preached from these engineers for years are just disregarded and thrown out of the window with this reckless use of LLMs on high profile project.

Just creating permanent cognitive debt for everyone else with no-one else understanding what the code is doing.

The cognitive debt is by design. Now everyone must use an LLM to maintain the codebase, because it's beyond any single human's capacity for understanding.

Part of the problem is that of human alienation. By excluding humans in the construction process, it has taken away any skin-in-the-game for humans. So, there could be a point where some bugs become unresolvable because LLMs dont have an adequate causal model and fixes by trial-and-error wont work in cases where root-causes are not properly addressed - and the project gets abandoned as a result. Witness the C compiler in rust [1], what happened to that after the initial press releases ?

[1] https://github.com/anthropics/claudes-c-compiler

This has been the case with IDEs as well. The most productive programmers have always delivered despite the tools they are forced to use not because of them. The less productive programs fail to learn because they are handheld by tooling.

The public contract previously discussed in RFCs and conference talks hasn't changed. Coding language is just an implementation detail.

Implementation details matter! Especially when reviewing the implementation.

Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.

While this is true, the fact that it is Rust provides a much greater level of confidence than if it was Python or something.

Confidence about what? That it works properly? Hopefully? Why don’t you read the 120k lines of code and tell us all how it works.

i feel like ppl have magical beliefs about type systems. just because it's _probably_ (did it use unsafe?) memory-safe doesn't mean it does what you want it to do

That's obviously true. On the other hand its also true this is more likely to work because it is rust compared to python or js for example. And that's not only because of memory safety. It's because static typing gives an automatic proof of a certain level of correctness of the code. That correctness is correlated with correct business logic bugs. So it is valid argument to make.

Of course that doesn't mean that there are no businesses logic bugs.

only if it is not littered with unsafe blocks

> Coding language is just an implementation detail

Sure, but what machine model do the public contract docs and RFCs target ? While the specific coding language is a detail, programming languages target a precise machine model. There is no machine model for english prompts and spec docs. So expect fuzziness - he-said-she-said bugs in your code - things that the LLM made up because the RFCs were not precise. And by the time you add precision to the specs, it has morphed into a new programming language with a machine model. In this usecase, since it is a port, the impact is mitigated because it is a clone of some existing functionality.

It was def ai generated work. If anything, this is a good use of ai.

Reply on news.ycombinator.com