Comments 13
Статья, как и полагается, достойна типичной it-компании: "что лучше картошка или молоко?"
Если задача имеет много зависимостей, особенно неявных, то LLM замедляет работу, как и любой кто не в теме. Задача программиста спроектировать в соответствии с принципами low coupling high cohesion, SMART (конкретность, измеримость/проверяемость, достижимость/ещё лучше если задачу уже много раз решали, релевантность/соответствие бизнес целям, ограниченность по времени), тогда можно задачу делегировать - LLM или джуну, неважно.
Проблема LLM что он почти никогда не сознается что ему не хватает знаний или контекста задачи, хотя для человека это очевидно. И он начнет их выдумывать, что совсем зашквар. Эту проблему не пофиксят ещё долго, жаль.
LLM только усиливают ошибки оценки периметра задачи, оценки её зависимостей, ошибки оценки трудоемкости, риски срыва сроков.
Вот это их сильный недостаток.
Вторым недостатком является что LLM generated code сразу становится legacy: контекст не живёт в голове человека, он не документирован. Это эквивалент того что разработчик ушёл и код стал легаси.
Потому что способ создания кода поменялся, а парадигмы разработки, проектирования и тестирования нет. В зтом и проблема. Например, допустим ты сгенерил класс, какие-то там методы и т.п. ты не сильно вникал что там внутри получилось, тебе важно чтобы оно делало то что надо и делало это хорошо. Очевидно что такой код должен иметь минимальную связность, должен быть покрыт тестом и должен иметь описание постановки задачи для ии, чтобы можно было его перегенерить сколько угодно раз. Код становится черным ящиком , и это нормально. Код становится дешевым, проектирование остается дорогим, даже становится ещё дороже. И не нужны там никакие анализаторы правильности кода, т.к. такой код должен восприниматься как черный ящик. Если черный ящик работат неправильно, он за несколько минут перегенерируется на новый черный ящик.
Вот что я имею в виду. Способ программирования поменялся, всё остальное осталось старым, хотя тоже должно поменяться.
Нет эффективного способа проверить, что черный ящик работает правильно в общем случае. Белый ящик из-за проблемы останова тоже однозначно не валидируется, но на практике работают всякие эвристики.
В частных случаях же вполне может работать и чёрный и белый ящик. Например, на код шейдера наплевать, если он рисует то, что требуется и делает это достаточно быстро - он же никак на наружу не влияет и его действительно можно перегенерировать при надобности.
Я не об этом. Я о том что к сгенерированнному коду почему-то предъявляются такие же требования как к рукописному, что само по себе нонсенс. Например если в сгенерированном есть дублирования кода, да и хрен с ним. Этот код вообще смотреть не надо. Надо лишь делать хорошие способы проверки работоспособности такого кода. Возможно в будущем будут более высокоуровневые языки которые будут выглядеть как правильно оформленная постановка задачи для ии, а сам код будет генериться в пайплайне. Вот я про что. Но тема новая, это всё только предстоит сделать и придумать.
Но другое дело когда ии делает маленький кусочек, а ты его потом допиливаешь. Но фактически ты полностью сам ревьюишь и дорабатывешь код. Но это другое.
Так сгенерированный код точно также должен работать и точно также нужно поддерживать, поэтому и требования такие же. Это логично. Другое дело, что требования, которые сейчас предъявляются бывают излишни, я уже приводил пример с шейдером, но из больше, конечно. Но и обратных примеров можно набросать.
Аналогия, что дескать раньше были компиляторы и мы переходили на языки более высокого уровня, и на смотрим во что они там компилируются, не работает, компилятор поведение программы никак не меняет (кроме производительности отчасти), оно задаётся программой. Про ИИ такого сказать нельзя.
Поэтому поведение должно быть зафиксировано тестами. Какой там будет сгенерирован в пайплайне код для реализации тестов не важно. Так что аналогию провести можно. И точно так же как рукописный, ии код поддерживать не надо, в этом и смысл. Надо поддерживать задачу которую ты ставил ии + тесты. Я ближайшее будущее вижу только так. Иначе ии это просто помощник программиста, как инструмент, но не более того.
Ну справедливости ради должен заметить что и текущая его роль сильно полезна. Я, например, недавно с его помощью решил задачу за которую без него даже не взялся бы, потому что было очевидно что это займёт неприемлемое количество времени. С ним мы справились довольно быстро.
Нюанс в том, что сравнивать нужно не только скорость, но и качество кода, время на дебаггинг и код-ревью. Потому что функция может генерироваться за десять минут, но если ревьювер возвращает ее три раза, а баг всплывает через месяц — где ускорение?
А вы знали, что не все компании могут позволить себе enterprise разработку - создавать код по всем принципам SOLID c тестами, pull request'ами и полноценным code review?
Из статьи получается, что вы исследовали влияние ИИ только на enterprise, что точно так же не отражает реальной ситуации
AIджун отлично справляется с шаблонным кодом. Но это только первый этап.
на тему использования
AIджуна в разработке — и везде разные цифры. Одни показывают ускорение, другие замедление, третьи — проблемы с качеством.
AIджун не знает вашего легаси, архитектурных ограничений и того, что функция для этого уже есть в соседнем модуле
AIджун не знает, что нужная функция уже есть в соседнем модуле, поэтому генерирует дубликат.
И вроде как негоже обвинять авторов исследований в некорректной постановке задачи, но, выводы вызывают много вопросов. Если уже есть какие-то готовые функции, скажи об этом в задании, если есть старые библиотеки - скажи об этом в задании.
Как будто можно посадить новичка за написание кода, а потом поставить в вину, что он не учел существующие библиотеки, про которые ему никто не сказал.
Шел 21 век … а люди все еще учились пользоваться AI-поиском 🤣
Короче говоря, непонятно кому верить, все исследования показали разные результаты в плане скорости. Может AI и позволяет писать код быстрее, но только в теории. Явных доказательств пока ещё нет.
Какой смысл приводить в качестве примера результаты годичной и более давности эксперименты? AI сегодня сильно не похожи на самих себя даже по состоянию на начало года. Все эти замеры и эксперименты устаревают в день публикации. Это как "вашему пятилетнему мальчику рано покупать велосипед с колесами 16", потому что три года назад он падал вот с того трехколесного велосипедика".
Ловушка искусственного интеллекта: действительно ли AI позволяет писать код быстрее