2 ms·

It's fascinating to read the comments here. The attitude is very strange to me. Writing software is not a sport that if you "cheat" using tools then your result

by mohsen1 4mo ago

It's fascinating to read the comments here. The attitude is very strange to me. Writing software is not a sport that if you "cheat" using tools then your results are worthless. Results are speaking for themselves. Unless you can provide a failing test case that the software presented here fails at then your arguments for "how" it was made is moot. Fully agentic coding is working well for projects like this since no matter how you write the code, the only way to truly know "it's working" is if it passes the test. With the right skills you can make well designed software with agentic coding too. It's not as easy as a simple "convert this to rust" prompt, at least today.

DannyBee 4mo ago
Agreed It reminds me very heavily of being on woodworking forums as ever more mass automation happened, and the infinite arguments around whether using power tools/CNC/etc was still "real woodworking". Lots of previously "hand-crafted" industries have dealt with mass automation. Software is not the first or the last. Hand-wringing by practitioners will change nothing, as it did not for any other industry. The vast majority of customers only care about the results, not the means. While there are some in the high end commission world who care about the art form, this is very rare and not sustainable for the majority. History says folks would be better off learning how folks survived and adapted in those industries, rather than trying to argue about how worthless or crappy the change is. Hobby wise, sure, whatever, but as a business what happens is very clear
- joeriddles 4mo ago
  Do you have any favorite books or resources on how folks in the past adapted to changes in their industries?
spicyusername 4mo ago
I think people will come around to accepting llm written code eventually, but it's hard having your entire career, and identity, upended overnight. Many people, myself included, have come to define themselves by their coding skills. They've taken great pride in not just solving the problem, but solving it in an elegant or nice looking way. Crisp comments, nice spacing, clever abstractions. In an age where an llm is better at scanning the code than you are, these things just do not matter anymore. Llms will be doing the debugging. Llms will be doing the writing. Llms will be doing the optimizing. And so all that matters is that llms can make sense of things. And they are much much better at making sense of things without the need for so many of the things that humans rely on as waypoints. The skill is no longer writing the code. It's solving the problems. Maybe it always was.
halJordan 4mo ago
It's not fascinating, it's tired and well trod territory. I'm disappointed that the HN community fell so willingly into the same hole drawing professionals fell into when Photoshop was released.
rererereferred 4mo ago
The issue in this particular project is how well maintained it will be in the long term, since it's chasing after another project with the goal of being 100% compatible. How many of these AI ports are just people chasing one shinny thing then moving on to the next?
crabbone 4mo ago
A lot of programmers naively believe that tests prove that the program works... Even though this has been repeated over and over again: tests can only prove that the program isn't broken in some specific way. When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an explanation ready. When you interact with LLM, it can generate an explanation, but, fundamentally, it doesn't work in the same way the flesh-and-blood programmer does. It doesn't really have an explanation. LLM can be right 99 times out of 100, where a human undertaking the same task might be right only 90 times out of 100, but the inability to find that 1 wrong case is scary. LLMs and live programmers make mistakes in different ways. You, the tester, can re-trace the thought process of a live programmer and detect errors where your outcomes don't match the outcomes produced by another programmer. You, however, cannot have the same though process as an LLM... that's physically impossible. So, once it's wrong, you are on a wild goose hunt after the error.
- mohsen1 4mo ago
  I personally think at some complexity level almost nobody who wrote the code can tell you what's going on. E.g. TypeScript's `checker.ts`
  - crabbone 4mo ago
    I think you are putting the cart before the horse: the code was written intentionally, i.e. someone first had a thought, and then fleshed it out in the code (and maybe had forgotten all about it the minute later). When LLM generates code, it also has a "thought process" of sorts. But it's very different from the one humans use. An LLM generating code may pretend to have a thought process similar to humans (when asked to elaborate on the reasons the code is this way or the other), but, fundamentally, it's going to be a lie, because the real reasons this LLM created the code in a particular way is very different, and is very hard to grasp for a human, even if they are familiar with the problem (there were some attempts at explaining LLMs "thinking" that would end up looking like heatmaps and other weird things that are useful for debugging them). Imagine that instead of a stack trace, the program you are debugging spits out only the memory dump with values in registers etc. (the gibberish-looking part of the coredump file). You'd be in a similar situation receiving the "true" explanation from an LLM generating your code.

by mohsen1 4mo ago

DannyBee 4mo ago

Agreed It reminds me very heavily of being on woodworking forums as ever more mass automation happened, and the infinite arguments around whether using power tools/CNC/etc was still "real woodworking". Lots of previously "hand-crafted" industries have dealt with mass automation. Software is not the first or the last. Hand-wringing by practitioners will change nothing, as it did not for any other industry. The vast majority of customers only care about the results, not the means. While there are some in the high end commission world who care about the art form, this is very rare and not sustainable for the majority. History says folks would be better off learning how folks survived and adapted in those industries, rather than trying to argue about how worthless or crappy the change is. Hobby wise, sure, whatever, but as a business what happens is very clear

joeriddles 4mo ago
Do you have any favorite books or resources on how folks in the past adapted to changes in their industries?

spicyusername 4mo ago

I think people will come around to accepting llm written code eventually, but it's hard having your entire career, and identity, upended overnight. Many people, myself included, have come to define themselves by their coding skills. They've taken great pride in not just solving the problem, but solving it in an elegant or nice looking way. Crisp comments, nice spacing, clever abstractions. In an age where an llm is better at scanning the code than you are, these things just do not matter anymore. Llms will be doing the debugging. Llms will be doing the writing. Llms will be doing the optimizing. And so all that matters is that llms can make sense of things. And they are much much better at making sense of things without the need for so many of the things that humans rely on as waypoints. The skill is no longer writing the code. It's solving the problems. Maybe it always was.

halJordan 4mo ago

It's not fascinating, it's tired and well trod territory. I'm disappointed that the HN community fell so willingly into the same hole drawing professionals fell into when Photoshop was released.

rererereferred 4mo ago

The issue in this particular project is how well maintained it will be in the long term, since it's chasing after another project with the goal of being 100% compatible. How many of these AI ports are just people chasing one shinny thing then moving on to the next?

crabbone 4mo ago

A lot of programmers naively believe that tests prove that the program works... Even though this has been repeated over and over again: tests can only prove that the program isn't broken in some specific way. When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an explanation ready. When you interact with LLM, it can generate an explanation, but, fundamentally, it doesn't work in the same way the flesh-and-blood programmer does. It doesn't really have an explanation. LLM can be right 99 times out of 100, where a human undertaking the same task might be right only 90 times out of 100, but the inability to find that 1 wrong case is scary. LLMs and live programmers make mistakes in different ways. You, the tester, can re-trace the thought process of a live programmer and detect errors where your outcomes don't match the outcomes produced by another programmer. You, however, cannot have the same though process as an LLM... that's physically impossible. So, once it's wrong, you are on a wild goose hunt after the error.

mohsen1 4mo ago
I personally think at some complexity level almost nobody who wrote the code can tell you what's going on. E.g. TypeScript's `checker.ts`
- crabbone 4mo ago
  I think you are putting the cart before the horse: the code was written intentionally, i.e. someone first had a thought, and then fleshed it out in the code (and maybe had forgotten all about it the minute later). When LLM generates code, it also has a "thought process" of sorts. But it's very different from the one humans use. An LLM generating code may pretend to have a thought process similar to humans (when asked to elaborate on the reasons the code is this way or the other), but, fundamentally, it's going to be a lie, because the real reasons this LLM created the code in a particular way is very different, and is very hard to grasp for a human, even if they are familiar with the problem (there were some attempts at explaining LLMs "thinking" that would end up looking like heatmaps and other weird things that are useful for debugging them). Imagine that instead of a stack trace, the program you are debugging spits out only the memory dump with values in registers etc. (the gibberish-looking part of the coredump file). You'd be in a similar situation receiving the "true" explanation from an LLM generating your code.