For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.
For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.
> mostly by humans
`mostly` is doing a lot lifting here. The Go rewrite uses plenty of copilot. The reason you trust it is because you trust the people doing the rewrite.
What about human written software makes it more reliable than LLM written software?
is it the craftsmanship, or the deliberate decision making of industry veterans?
It's the notably poor quality of LLM-generated code
As opposed to the incredible code that humans are known to write...
If attention is all we need then what is better
Hours of human attention
or a few seconds of AI attention?
I am not just talking about writing the code but the brainstorming that goes into it.
Many projects that were done by humans and took a year can certainly not be trusted.
AI is a great use for this kind of boring, rote translation where precision is important. Humans are quite bad at it and tend to make mistakes. In either case the focus should be on improving testing, not trying to manually verify if the translation was correct by eye.
I have an issue with the precision of generated code.
LLMs sometimes confidently leave things out or they will overbuild.
I use them all the time but mistakes happen. It's not exactly a scalpel, more like a sledge hammer.
With programs large enough tests aren't going to ever be enough. Formal verification might work, but then who checks the specification for bugs?
I really wonder where all of these people who believe that tests perfectly encapsulate the behaviour of software come from. Maybe it's because LLMs happen to work better when you give them acceptance criteria and people struggle to distinguish between "better" and "good"?
The real test is years in production. Over time your test suite grows when bugs are found and fixed, but not every bugfix necessarily gets a test, and it's very rare that a bugfix is exhaustively tested. Relying on the test suite as a directional indicator that your vibecoded rewrite functions something like the original is probably sensible. But it isn't "done" until you've run it in production for at least as long as the original. And that's where it all falls apart, because maintenance will be a nightmare. Nobody knows how the new thing works.
In the case of rewrites, the specification is the original behavior, no? bugs and all.
Deciding if two programs do the same thing is provably impossible in the strict mathematical sense.
There is often no spec, just the old code, copied with the old bugs and with new ones sprinkled on top.
If precision is important then non deterministic AI is simply not a good tool.