Эдвин Гнихтел видел несколько больших шариков грязи в свое время — и под грязью, он имеет в виду устаревшие приложения и ИТ -системы.
Gnichtel является генеральным директором CodeLogic, платформы автоматизации программного интеллекта, которая развертывает ИИ для разрешения технического долга. Ранее он был главным технологическим директором CodeLogic, а также работал в области разработки программного обеспечения низкого уровня.
Это так плохо, это сложно на графике, — сказал он аудитории в Infobip Shift Miami, конференции разработчика, ориентированная на ИИ.
«Почему у нас 75 000 занятий?» Он спросил. «Это реальное число из реальной системы. Кстати, это была только одна система, которая была частью гораздо большей экосистемы систем».
Причины развития технического долга
Есть много причин технического долга в разработке. Он обвинил Agile в том, что он добавил к долгу благодаря его бесконечному толчке к производству, добавив, что, хотя он является сторонником Agile, его сосредоточено на быстром доставке ускоряет технический долг, определяя приоритеты функций по сравнению с качеством кода.
Кроме того, он указал на системы, основанные на устаревших рамках. Кроме того, никто больше не делает системную архитектуру, добавил он. Он также обвинил неправильное толкование микросервисов.
«Сколько организаций думают, что, как и у них есть существующая вещь, и просто просто закрыть ее в контейнер, волшебным образом сделало это микросервисом?» спросил он риторически.
Он показал график знаний о меньшем применении с «простой» 5000 классов, 34 000 методов, 300 таблиц, 4700 кв.
График множества зависимостей небольшого приложения.
«Когда вы попадаете в более крупное приложение, я не могу даже представить визуально», — сказал он. «[IT] Был бы просто каплей цвета на экране ».
Роль ИИ в техническом долге
В этот грязный беспорядок мы добавляем код, сгенерированный AI.
«ИИ может ухудшить это впечатляюще», — сказал он. «Это написано поверх целой кучи мусора [which] В конечном итоге не делает для большого результата. Итак, мы ведем технический долг ».
Организации имеют дело с бесконечным обслуживанием кода. Проще говоря, это уже не проблема, которую могут решить, что люди могут решить.
Но, может быть, ИИ может.
Подход CodeLogic заключается в том, чтобы сначала отобразить сложность системы, используя агент ИИ для создания большого графа знаний.
«Во многих случаях тонны зависимостей действительно становятся видимыми только при выполнении кода — например, такие вещи, как процедурно сгенерированные объекты соединения, определенные типы построенных запросов базы данных, всевозможные такие вещи», — сказал он.
Среда исполнения, переводчики и среда сборки, которые включают компиляторы, любят вводить вещи, добавил он. Например, Java использует Lambdas. Лэмбдас на самом деле не существует, сказал он. Когда вы смотрите на байтовый код, он просто преобразуется в классы и методы, объяснил он.
«Это плод воображения Явы», — сказал он.
Все эти зависимости должны быть захвачены, добавил он. Модель данных CodeLogic, которая находится под продуктом, предлагает дифференциальный анализ и предоставляет информацию о влиянии, чтобы помочь компании понять, как все связано.
Сложные решения с ИИ
Использование CodeLogic нескольких моделей показывает, как могут быть построены сложные системы с помощью ИИ.
CodeLogic всегда планировал использовать машинное обучение и другие технологии искусственного интеллекта, но они не ожидали, так это то, как быстро модели улучшатся, когда они сложены модели, развернут сервер MCP и использовали другие методы для улучшения моделей крупных языков.
«Это позволило нам действительно перенести эту проблему», — сказал он.
Поиск дополненного поколения с помощью MCP -сервера позволил им «поговорить» с LLMS, указывать на код, который должен быть рассмотрен. Анализ воздействия выявляет все части, которые может повлиять на переписывание, в том числе кусочки, которые находятся в нескольких «хмеле», таких как конечные точки REST, границы API и базы данных.
Процесс не всегда прост и может включать в себя повторное высказывание и проверки на кодологическую систему, чтобы понять, что знает ИИ. Он должен быть отслежен, чтобы убедиться, что он не нарушает зависимости, сказал он. Человек в цикле также необходим для утверждения изменений.
CodeLogic создает дифференциальный анализ многографа, который может начать генерировать все необходимые наборы дисков. Это интерпретируется моделью, которая затем генерирует дифференциальный набор. Дифференциальный набор интерпретируется еще одной моделью, которая генерирует наборы подсказок и билетов.
Они могут быть помещены в Джиру, чтобы ИИ мог быть привлечен к ответственности за закрытие билетов.
«В конце концов, ключевая часть — это также пишет подсказки», — сказал он. «Эти подсказки могут стать довольно изощренными, а затем это возвращается прямо в дополненный ИИ на стороне поколения, на стороне генерации кода, которая затем позволяет вам сделать все, что сделано».
Последняя часть помогает разработчикам прекратить создание технического долга. Например, разработчик может спросить систему CodeLogic, что произойдет, если введена конкретная версия библиотеки.
«У нас есть функциональность вокруг нашего языка аннотации, где, если вы вносите изменения, люди получают уведомление [and] Последствия на руке возникают », — сказал он.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Loraine Lawson — ветеран -репортер, который в течение 25 лет освещал технологические проблемы от интеграции данных до безопасности. Прежде чем присоединиться к новому стеку, она работала редактором Banking Technology Site Bank Automation News. Она … читайте больше от Лорейн Лоусон
