Комментарии 15
но не обязательно будет знать, как создать эффективный код, который использует все возможности более современного языка.
Какая у вас скорость печати?
2000 знаков в минуту.
Ого! Действительно так быстро?!
Да, правда получается полная ерунда.
Так ведь уточнили, что его использовали не для прямого перевода кодовой базы на другой язык, а для того чтобы перевести его в понятную и легко читаемую архитектуру, которую уже потом разработчики реализовали на другом языке
Изучение старой кодовой базы это как раз таки бутылочное горлышко таких процессов мне кажется
Которую отдали реализовывать мясным мешкам ручками
Как предотвратить галлюцинацию при переводе в спецификацию? Сжатие текстов на LLM тоже приводит к галлюцинациям. Чтобы избежать багов, нужен человеческий контроль за процессом. Нужно посмотреть на спецификацию, заглянуть в старый код, и понять его до определенной степени. Экономия выходит на наборе текста.
Инструмент переводил устаревшие языки программирования в простые английские спецификации, которые можно переписать в современном коде.
Вы читаете что публикуете?
Инструмент имеет ограничения, касающиеся переписывания больших участков кода. Так, он технически может переписать код со старого языка, например Perl, на новый, например Python, но не обязательно будет знать, как создать эффективный код, который использует все возможности более современного языка.
Перевод: ребята решили хайпануть, но внезапно оказалось, что генерируемый новый код не рабочий. Чтобы тем не менее хайпануть оставили перевод в спецификации на natural language. Без примеров обсуждать полезность такого подхода (а не человеко-чтения старого кода перед разработкой нового) сложно.
Между
"переписали 9 млн строк устаревшего кода и сэкономили 280 тысяч часов"
и
"проанализировал 9 млн строк устаревшего кода, сэкономив разработчикам примерно 280 тысяч часов"
Совсем нет разницы? Что за чудаки работают в новостном отделе?
переписали в спецификации
Да и 280 тысяч часов замечательно само по себе - спецификацию, в отличии от кода, не оттестируешь, так что можно хайпать пока по ней не начнут проверять код написанный по спеку. Но к тому момент премия и повышения за сэкономленные 280 тысячь часов (sic!) будут уже получены и успешно пропиты. Идеальное сочетание, и звучит громко и не проверишь.
Мы тоже такое делали, как не подгоняли различные модели, все равно ошибок в спецификациях куча. На поверхностном уровне кажется крутой фичей. Для маркетинга компании конечно супер тема побить себя в грудь, но на деле сомневаюсь, что в в этой компании кто-то из технарей будет доверять результату. Оговорки, что мол "доглядим, доправим" на деле никто не станет. Можно также попытаться списать на "неопытность" пользователя в нашем случае. Но вот про количество часов... на 100 поделить может и в какой метрике? Если в метрике написания спецификации, то да, разумно, но вряд ли столько. Если в метрике реальной пользы за вычетом рисков, то затрудняюсь ответить
Тот неловкий момент, когда ты целый год учил Cobol чтобы зашибать миллионы, но остался без работы.
Мне так кажется при такой постановке вопроса "целый год учить кобол" заранее было обречено на провал. Человек которому на это надо целый год вряд ли зашибет миллионы, просто потому что работа связанная с коболом - это в превую очередь разбираться (то есть учить) куда более сложную вещь - а че же там на этом коболе написано. И с такой скоростью обучения - миллионов там не зашибешь. Так что возможно как раз ловкий момент, спасает от еще большего разочарования когда будет потрачено еще больше усилий, а миллионов все не будет. В каждой проблеме можно увидеть возможность, миллионы они так делаются :-)
В Morgan Stanley благодаря ИИ-инструменту переписали 9 млн строк устаревшего кода и сэкономили 280 тысяч часов