Hacker News Reader

Comment by Swiffy0 | Hacker News Reader

Not sure what to think of this.

Sure, a Rust implementation will perform better and use less RAM, but it's quite obvious that the transition to Rust will be done almost entirely by AI.

Don't get me wrong, the AI coded Rust version of Discord will most likely work just fine. The thing I'm wondering about is if it's a good idea to rewrite your whole codebase (which I assume is handwritten since Discord predates AI coding) with AI because now there is nobody that knows how it really works - I'm wondering what's the value of having a human-written codebase + the people who wrote it. Just feels like one shouldn't throw that into the trash like it's nothing?

View on HN

I'm with you and I think a variety of companies are going to learn this in a highly expensive way over the next few years. Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back. Like what would you even do if you change your mind in 3 years - sit everyone down to meticulously comb through all the AI code until they start to get how it works? Getting back to a similar level of understanding seems like it would take ages and effectively locks you into the new solution in a way that cannot be feasibly reversed.

How is this different from when you join a company and learn your corner of the codebase? In a sufficiently large enough codebase no one had the whole mental model in their head even before AI. What you did was find and ask that one person who knew enough about some part of the project to answer your questions. Now you can ask a model.

I believe institutional knowledge used to work on a ship of Theseus model. It's going to be completely different going forward.

> How is this different from when you join a company and learn your corner of the codebase?

Because most AI generated code is incredibly verbose and noisy. This can be true for any codebase, but it is especially egregious in AI codebases. It is hard to prevent that by just saying "be concise" because knowing exactly where to be concise is the measure of true skill/intelligence.

Every time I have success with AI coding, it is because whatever I need done can work as a pure function, where the probability I have to return to it is very very low.

Making sense of a codebase is like putting together a puzzle. A purely AI generated codebase is like trying to put it together without a picture on the pieces.

This is more like ALL the developers have just joined a company where no other devs work and can pass along institutional knowledge. You know, the thing that makes all that complexity wieldy.

Also Reflections on Trusting Trust taken to a whole new level.

Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back.

You won't want it back. How much time do you spend surfing through your .o or .obj files today?

Back in the day you'd read reference manuals which would tell you about the library, they might be hand written or a listing of the addresses and names. Today in the modern day, we still use reference manuals for writing C and C++. It's just encoded in websites, e.g. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c... and https://en.cppreference.com/

But there are still libraries where familiarising yourself with the header is important, for example stb's libraries. man(1) and GNU Info were both invented to be computer-stored reference manuals, and indeed to this day you can type `man 3p open` to get the POSIX documentation of the system up in front of you.

I am not aware of many codebases that have manuals as complete as this, but back in the day (1970s-era to the 1990s-era) there would be internal documentation written as par of course for the specification created by the waterfall model of development. Post-2010 companies are very lackadaisical about documenting internal interfaces and libraries because they come from startup cultures where "move fast and break things" is the name of the game.

> How much time do you spend surfing through your .o or .obj files today?

Those are not the source of truth for the application logic. But the higher level code is.

The application code describes the behavior of the program and the compiler translates it into a different representation following a set of known, deterministic rules. This is unlike an LLM producing code from a prompt, which is why the source code is still the source of truth, and not a bunch of prompts.

Determinism is something you'll have to give up if you want to stay employed, I'm afraid.

The solution, as usual in engineering, is negative feedback. Unfortunately, many people around here think that means "Shoot the messenger."

I'd say they're betting on AI getting good and reliable enough to not have to go back to the "old" practice.

But are they betting more than they can afford to lose, is the thing.

Yes, I wouldn't make that bet.

>change your mind in 3 years

I think if people change their mind in six months, let alone 3 years, they would just rewrite it again with something different, or just double down on the AI rewrite to rewrite the rewrite to fix the gaps and so on. It's a rabbit hole.

What people are completely missing with AI is that when a company/someone makes the decision (which is most these days) to go heavily on the AI route, they are probably going to keep going that way.

We don't really know what’s the right balance of AI and People right now.

My personal take would be to leverage AI to fix and improve what already exists in a maintainable way and wait for others to experiment with going heavily AI. It's worked great for Apple who is generally years behind in a lot of things because they wait it out for others to experiment with things.

I don’t think this changes just because you don’t do a rewrite. This is happening already as engineering leans more on AI tools in our own company.

Things ship and change way too fast and the changes are massive.

It seems like the value is having something performant. Their choices were 1) stick to a web framework their employees know well 2) a performant native app their employees don’t know as well. And they chose 2.

If a model can tell you anything you’d hope to have a human tell you, what’s the difference? It’s a different point of failure— models can go offline, but employees can also quit anytime too.

Would i rather have a massively bloated cross-platform electron app, or a native app in rust assisted by ai?

the native app wins every single time. Give me native or give me death!

I share the intuition but pragmatically if the codebase will only ever be interacted with through AI agents it probably is nothing and wouldn't matter anyway. You can probably even generate an exhaustive amount of documentation instantaneously if you are concerned about a human knowing their way around.

You’d think we learned this during all the front-end rewrites of the 2010s…

When porting an app this way, don't functions/classes preserve the same functionality ?

Well not really? You are going from a webpage (Electron) to a native application via Rust. Say you port a React website to a Rust native application, is anything about that code actually similar?

With GPUI quite a lot can be shared. Styling is similar, components can have same names. If your application logic is already cleanly separated, the resulting code can be quite similar.

I think there are lots of common patterns you find in GC’d languages that don’t translate well into idiomatic rust.

Consequently, porting my game engine from Java to Rust was more challenging than I had anticipated.

Your entire opinion is founded on assumptions.

Reply on news.ycombinator.com