> So swapping languages, yeah maybe, but I expect of more practical use would be the situation where you inherit a legacy codebase in an ancient version of a language or framework that hasn't been loved in a long time. I saw this so many times when doing dev team for hire work.
I'm exploring this problem space - this is a wide spread pain point across almost all companies that are older than 3 years old. I've seen this at tech startups as well as very large companies and anything in between. Dropbox is arguably a top tier engineering organization that probably manages tech debt as responsibly as can be expected and they still had to make major investments to move their codebase forward from various eras of web tech
1) https://dropbox.tech/frontend/the-great-coffeescript-to-type...
2) https://dropbox.tech/frontend/edison-webserver-a-faster-more...
Everyone else is much worse off so the investment required to move forward is usually immense. This leads to full rewrites. Which is nice but error prone and sometimes entails huge opportunity costs
> Obviously you'd want to do boat loads of testing and there may well be manual work left to do afterwards, but I think it would be the kind of manual work that felt like you were polishing something new and clean and beautiful rather than trying to apply bits of sticky tape to something unmaintainable.
Agreed. In my opinion, now's a great time to get started with a semi automated approach like this while betting that the program synthesis and code generation capabilities will rapidly improve over the next few years. Larger context windows, solutions for hallucinations / reliability and better training data will help reduce the manual labor required.
> I also wonder about eventually being able to say to an LLM "take this codebase and make it look like my code", or maybe one of your favourite open source developer's code. Maybe everyone could end up with their own code style vector attached to their github profile describing their style. You could find devs with styles close to yours to work on your team, or maybe find devs with styles different to yours so you could go and argue about tabs vs spaces or something.
I've been thinking that personal style / training / fine tuning could become somewhat of an asset. "You are a principal software engineer at Google with particular expertise migrating codebases from {sourcelang} to {targetlang}." works fine but imagining a much richer portable input would possibly be quite valuable.
I’ve encountered lots of companies that keep paying license fees to oracle for DBs that could just as well be Postgres but for the work of updating and testing the code…
I'm exploring this problem space - this is a wide spread pain point across almost all companies that are older than 3 years old. I've seen this at tech startups as well as very large companies and anything in between. Dropbox is arguably a top tier engineering organization that probably manages tech debt as responsibly as can be expected and they still had to make major investments to move their codebase forward from various eras of web tech 1) https://dropbox.tech/frontend/the-great-coffeescript-to-type... 2) https://dropbox.tech/frontend/edison-webserver-a-faster-more... Everyone else is much worse off so the investment required to move forward is usually immense. This leads to full rewrites. Which is nice but error prone and sometimes entails huge opportunity costs
> Obviously you'd want to do boat loads of testing and there may well be manual work left to do afterwards, but I think it would be the kind of manual work that felt like you were polishing something new and clean and beautiful rather than trying to apply bits of sticky tape to something unmaintainable.
Agreed. In my opinion, now's a great time to get started with a semi automated approach like this while betting that the program synthesis and code generation capabilities will rapidly improve over the next few years. Larger context windows, solutions for hallucinations / reliability and better training data will help reduce the manual labor required.
> I also wonder about eventually being able to say to an LLM "take this codebase and make it look like my code", or maybe one of your favourite open source developer's code. Maybe everyone could end up with their own code style vector attached to their github profile describing their style. You could find devs with styles close to yours to work on your team, or maybe find devs with styles different to yours so you could go and argue about tabs vs spaces or something.
I've been thinking that personal style / training / fine tuning could become somewhat of an asset. "You are a principal software engineer at Google with particular expertise migrating codebases from {sourcelang} to {targetlang}." works fine but imagining a much richer portable input would possibly be quite valuable.