LLM под капотом

Забавный кейс про 700000 строчек дремучего кода

Я давно не рассказывал про новые кейсы, т.к. проекты в основном встречаются повторяющиеся. В основном это data extraction - извлечение данных из PDF data sheets, purchase orders (с последующей сверкой или интеграцией). Иногда встречается какой-нибудь интересный поиск по документам.

Но вот появился принципиально новый интересный кейс применения LLM. На самом деле, он старый, но я лично с подобными масштабами не сталкивался.

Итак, есть одна компания, которой больше 100 лет. У нее есть своя самописная ERP система. Это система будет помоложе компании, и она написана на языке разработки бизнес-приложений со времен мейнфреймов, которому уже более 40 лет (для сравнения, 1C - моложе). БД в этой среде своя - проприетарная, интерфейс - терминал 80x25. Кода там - 700000 строчек, преимущественно CRUD и бизнес-логика рядом.

Это не IBM AS/400 с DB2, но что-то очень близкое по духу. Но и тут нужно платить дорогие лицензии, а разработчиков найти практически невозможно.

Компания хочет обновить код на что-то посовременнее. Не ради современности, а для того, чтобы были живые разработчики, которых можно нанять. Заодно клиент хочет еще и интерфейс сделать современным, но так, чтобы все горячие клавиши и последовательности символов работали, как раньше.

Соответственно, возник вопрос в системной оценке проекта - можно ли здесь как-нибудь ускорить процесс переписывания при помощи LLM, как вообще подходить к проекту, какие риски могут быть, как их лучше “вскрыть” пораньше?

И если начать копать, то получается интересная картина. В этой формулировке проекта компания смешала две разные задачи в одну кучу. И лучше бы их разделить, чтобы не умножать риски сверх нужды (я видел проекты, которые на этом погорели).

Первая задача - модернизация кода и перенос ERP системы с дремучего языка на JVM, без изменения терминального интерфейса. Функционал остается тот же самый, просто код читаем и не нужно платить адские суммы в год за лицензии.

Вторая задача - берем портированный и вычищенный код и уже свежими силами переписываем терминальный интерфейс на более “красивый” со всяким React/Desktop итп.

Так вот, в такой формулировке меньше всего рисков в первой части, т.к. можно использовать современные модели для ускорения анализа и переноса (Gemini Pro 2.5 очень удачно вышел). Но, самое главное - scope проекта: чтобы все работало точно так же, как и раньше, но только в браузере или в современном терминале.

А у терминальных приложений есть одна приятная черта - их достаточно просто протестировать на работу “точно так же”. Сажаем эксперта за оригинальное приложение, делаем snapshot БД и просим его реализовать какой-то сценарий работы. В процессе записываем каждую нажатую клавишу и состояние буфера экрана. Потом берем новый код, который портировали полуавтоматическим методом, прогоняем те же клавиши и сравниваем экран терминала с эталоном после каждого шага. Если нет совпадения на 100%, значит что-то упустили.

Вторая задача - это уже обычная разработка (там можно использовать обычный инструментарий из AI Coding, но это не принципиально). Тут уже куча рисков, т.к. надо придумывать новый UI, писать под него тесты, отлаживать итп. Тут не просто механическое портирование кода, а думать надо. Но это типичная задача по разработке на достаточно современном языке программирования, ее решение известно. И этим можно заняться после первой задачи.

В общем, получается довольно забавный кейс, где использование LLM/AI - это не самоцель, а просто один из инструментов, который можно достаточно удобно вписать в картинку проекта на системном уровне. Можно даже обойтись и без него, но уж больно людей жалко.

Ваш, @llm_under_hood 🤗

www.group-telegram.com/us/llm_under_hood.com/569

10.0K viewsedited  May 14 at 10:52

Забавный кейс про 700000 строчек дремучего кода

Я давно не рассказывал про новые кейсы, т.к. проекты в основном встречаются повторяющиеся. В основном это data extraction - извлечение данных из PDF data sheets, purchase orders (с последующей сверкой или интеграцией). Иногда встречается какой-нибудь интересный поиск по документам.

Но вот появился принципиально новый интересный кейс применения LLM. На самом деле, он старый, но я лично с подобными масштабами не сталкивался.

Итак, есть одна компания, которой больше 100 лет. У нее есть своя самописная ERP система. Это система будет помоложе компании, и она написана на языке разработки бизнес-приложений со времен мейнфреймов, которому уже более 40 лет (для сравнения, 1C - моложе). БД в этой среде своя - проприетарная, интерфейс - терминал 80x25. Кода там - 700000 строчек, преимущественно CRUD и бизнес-логика рядом.

Это не IBM AS/400 с DB2, но что-то очень близкое по духу. Но и тут нужно платить дорогие лицензии, а разработчиков найти практически невозможно.

Компания хочет обновить код на что-то посовременнее. Не ради современности, а для того, чтобы были живые разработчики, которых можно нанять. Заодно клиент хочет еще и интерфейс сделать современным, но так, чтобы все горячие клавиши и последовательности символов работали, как раньше.

Соответственно, возник вопрос в системной оценке проекта - можно ли здесь как-нибудь ускорить процесс переписывания при помощи LLM, как вообще подходить к проекту, какие риски могут быть, как их лучше “вскрыть” пораньше?

И если начать копать, то получается интересная картина. В этой формулировке проекта компания смешала две разные задачи в одну кучу. И лучше бы их разделить, чтобы не умножать риски сверх нужды (я видел проекты, которые на этом погорели).

Первая задача - модернизация кода и перенос ERP системы с дремучего языка на JVM, без изменения терминального интерфейса. Функционал остается тот же самый, просто код читаем и не нужно платить адские суммы в год за лицензии.

Вторая задача - берем портированный и вычищенный код и уже свежими силами переписываем терминальный интерфейс на более “красивый” со всяким React/Desktop итп.

Так вот, в такой формулировке меньше всего рисков в первой части, т.к. можно использовать современные модели для ускорения анализа и переноса (Gemini Pro 2.5 очень удачно вышел). Но, самое главное - scope проекта: чтобы все работало точно так же, как и раньше, но только в браузере или в современном терминале.

А у терминальных приложений есть одна приятная черта - их достаточно просто протестировать на работу “точно так же”. Сажаем эксперта за оригинальное приложение, делаем snapshot БД и просим его реализовать какой-то сценарий работы. В процессе записываем каждую нажатую клавишу и состояние буфера экрана. Потом берем новый код, который портировали полуавтоматическим методом, прогоняем те же клавиши и сравниваем экран терминала с эталоном после каждого шага. Если нет совпадения на 100%, значит что-то упустили.

Вторая задача - это уже обычная разработка (там можно использовать обычный инструментарий из AI Coding, но это не принципиально). Тут уже куча рисков, т.к. надо придумывать новый UI, писать под него тесты, отлаживать итп. Тут не просто механическое портирование кода, а думать надо. Но это типичная задача по разработке на достаточно современном языке программирования, ее решение известно. И этим можно заняться после первой задачи.

В общем, получается довольно забавный кейс, где использование LLM/AI - это не самоцель, а просто один из инструментов, который можно достаточно удобно вписать в картинку проекта на системном уровне. Можно даже обойтись и без него, но уж больно людей жалко.

Ваш, @llm_under_hood 🤗

BY LLM под капотом