Здравствуйте, AleksandrN, Вы писали:
AN>У кого какой опыт разработки с использованием LLM? В каких случаях ускоряет, а в каких — нет?
Я не оч понимаю как можно писать код не имея опыт в проекте (а АИ не имеет по факту)
Бойлерплейт можно писать с нуля.
WBR, Igor Evgrafov
Re: Использование LLM в больших проектах замедляет разработч
Вот если господин робот будет делать то что он умеет лучше, т. е. не служить мужику, а контролировать и пороть мужика...
Утверждение о том, что AI повышает производительность, мягко говоря, не совсем точно. Включение AI-ревьюера снижает производительность и увеличивает время выполнения задачи.
Вместо этого оно существенно повышает качество. Наверное, это тихая революция в software engineering, потому что количество найденных идиотизмов и ошибок зашкаливает. Через несколько лет, когда ai-reviewed код начнёт составлять ощутимый процент от общей кодовой базы мы начнём видеть синергентический эффект этого. Что-то поменяется (если к тому времени AI не перепишет всё к чертям, во что я не верю).
Оно повышает не лучшее качество, оно повышает худшее качество. Миллион глупостей остающихся в коде, документации, ранбуках и т.д. внезапно оказываются хотя бы частично исправлены.
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
AN>У кого какой опыт разработки с использованием LLM? В каких случаях ускоряет, а в каких — нет?
ну ведь давно известно же что добавление разработчиков замедляет проект, пофиг что разработчик — искуственный, правило одно для всех)
Как много веселых ребят, и все делают велосипед...
Re: Использование LLM в больших проектах замедляет разработчиков
Здравствуйте, AleksandrN, Вы писали:
AN>Исследование https://arxiv.org/abs/2507.09089 AN>У кого какой опыт разработки с использованием LLM? В каких случаях ускоряет, а в каких — нет?
Ускоряет когда ты полный нуль в чем-либо, к примеру я не знаю Python вообще, за всю жизнь 10 строчек написал. Так вот когда нужно написать скрипт — оно реально ускоряет. Но скрипты все очень простые мне нужны, а сам я бы их писал долго, т.к. прежде чем написать — нужно прочитать целую книжку.
=сначала спроси у GPT=
Re[2]: Использование LLM в больших проектах замедляет разработчиков
Здравствуйте, Shmj, Вы писали:
S>Ускоряет когда ты полный нуль в чем-либо, к примеру я не знаю Python вообще, за всю жизнь 10 строчек написал. Так вот когда нужно написать скрипт — оно реально ускоряет. Но скрипты все очень простые мне нужны, а сам я бы их писал долго, т.к. прежде чем написать — нужно прочитать целую книжку.
А если ИИ скрипт напишет, можно сразу пихать его в рабочую среду, даже не понимая, как он работает.
Re[3]: Использование LLM в больших проектах замедляет разработчиков
Здравствуйте, Privalov, Вы писали:
S>>Ускоряет когда ты полный нуль в чем-либо, к примеру я не знаю Python вообще, за всю жизнь 10 строчек написал. Так вот когда нужно написать скрипт — оно реально ускоряет. Но скрипты все очень простые мне нужны, а сам я бы их писал долго, т.к. прежде чем написать — нужно прочитать целую книжку.
P>А если ИИ скрипт напишет, можно сразу пихать его в рабочую среду, даже не понимая, как он работает.
Обычно все понятно — если что-то не понятно — можно спросить, запустить и проверить что все именно так и работает.
=сначала спроси у GPT=
Re: Использование LLM в больших проектах замедляет разработчиков
Здравствуйте, AleksandrN, Вы писали:
AN>У кого какой опыт разработки с использованием LLM? В каких случаях ускоряет, а в каких — нет?
Однозначно сильно ускоряет при работе с декларативными языками и типичными для них задачами — CI, системы сборки и т.п. Пример: несколько лет назад я настраивал сложную сборку на Azure DevOps (много платформ, компиляторов, кодогенерация и т.п.). Любой шаг чуть в сторону от примера в документации мог закончится множеством циклов "поменяй — закомментируй — запуш — запусти — читай лог ошибки", т.к. локально не проверить. Вложенные специальные симовлы, разные окончания строк и т.п. вызывали много боли. Сейчас делал похожие задачи на Jenkins + AI — потратил в разы меньше времени. IMHO, для CMake AI пишет код лучше чем 90% людей. Скрипты на Bash, PowerShell, Python тоже обычно хорошо.
С другой стороны вообще не помогает разобраться в сложных проблемах, например, когда есть падаение на стороне заказчика которое не воспроизвести локально и стэк вызова.
Вывод стандартный — полезная утилита если применять с умом, не серебрянная пуля. В среднем по больнице, небольшой прирост производительности дает даже в корпоративной среде.
Re[2]: Использование LLM в больших проектах замедляет разработчиков
S>Ускоряет когда ты полный нуль в чем-либо, к примеру я не знаю Python вообще, за всю жизнь 10 строчек написал. Так вот когда нужно написать скрипт — оно реально ускоряет. Но скрипты все очень простые мне нужны, а сам я бы их писал долго, т.к. прежде чем написать — нужно прочитать целую книжку.
Тоже есть сомнения на этот счет.
Вот если бы тебе надо было написать один скрипт — да, ИИ нагененрил бы его быстрее.
Но если тебе надо написать набор скриптов (пусть даже не связанных логически друг с другом) — может оказаться, что сам ты напишешь быстрее. Потому что пока пишешь первые скрипты — натренируешься, и следующие будешь писать уже быстрее.
Re[2]: Использование LLM в больших проектах замедляет разработчиков
Здравствуйте, Skorodum, Вы писали:
AN>>У кого какой опыт разработки с использованием LLM? В каких случаях ускоряет, а в каких — нет? S>Однозначно сильно ускоряет при работе с декларативными языками и типичными для них задачами — CI, системы сборки и т.п.
Ага, я как-то озвучивал, что devops-ы пользуют AI в полный рост уже более двух лет, но это была их маленькая тайна ))
Действительно, небольшие по размеру и сложности задачи AI решает великолепно, помогает находить мелкие описки и прочие забытые случайно строки конфигурации.
Re[2]: Использование LLM в больших проектах замедляет разработчиков
S>Однозначно сильно ускоряет при работе с декларативными языками и типичными для них задачами — CI, системы сборки и т.п. Пример: несколько лет назад я настраивал сложную сборку на Azure DevOps
Иными словами, там, где человек не разбирается (потому что не для человека писали этот код, а для машины), и потому не знает, что делает, генерация "похожих на правду" скриптов дает ожидаемый эффект.
Еще 2 года назад это было понятно. Технология снижает "входной барьер", позволяя даже "не-программисту" что-то запрограммировать. Поэтому и бьют в колокола — с этой технологией джуниор-девелоперы становятся мало кому нужны. Но сеньором ведь сразу не станешь...
Re[3]: Использование LLM в больших проектах замедляет разработчиков
Здравствуйте, SkyDance, Вы писали:
SD> с этой технологией джуниор-девелоперы становятся мало кому нужны. Но сеньором ведь сразу не станешь...
Вооружённым бредогенератором один джуниор может выбить из колеи несколько синьёров, бомбардируя пул реквестами и пускай там пытаются понять, что это такое похожее на правду нагенерило и где в куче ai slop рациональное зерно, а где галлюцинация.
Re[3]: Использование LLM в больших проектах замедляет разработчиков
Здравствуйте, SkyDance, Вы писали:
SD>Иными словами, там, где человек не разбирается (потому что не для человека писали этот код, а для машины), и потому не знает, что делает, генерация "похожих на правду" скриптов дает ожидаемый эффект.
Не очень понимаю твою мысль Любой код пишется для машин, но читается людьми.
Я пытался сказать, что с точки зрения синтаксиса декларативные и императивный языки могут быть одинаково сложными для чтения, но в декларативных языках обычно есть много нюансов которые в документации явно не учтены или указаны в самых общих терминах. Сообщения об ошибках тоже очень размытые.
Условно: почему С-шный код делает не то, что ожидается, понять намного легче, чем почему пример из документации по QML выглядит совсем не так как ожидается, когда он скопирован в пользовательское окружение.
SD>Еще 2 года назад это было понятно. Технология снижает "входной барьер", позволяя даже "не-программисту" что-то запрограммировать. Поэтому и бьют в колокола — с этой технологией джуниор-девелоперы становятся мало кому нужны. Но сеньором ведь сразу не станешь...
Кто бъет-то?
Re[4]: Использование LLM в больших проектах замедляет разработчиков
S>Я пытался сказать, что с точки зрения синтаксиса декларативные и императивный языки могут быть одинаково сложными для чтения, но в декларативных языках обычно есть много нюансов которые в документации явно не учтены или указаны в самых общих терминах. Сообщения об ошибках тоже очень размытые.
Дело не в "декларативности" или "императивности" языка, а в том, что большинство этих DSL сделаны по принципу "мы решали свою местечковую задачу". И обычно эта задача имеет очень широкий контекст. Нужно понимать кучу (порой весьма необычных/странных/кривых/текущих) абстракций. У этих DSL'ей обычно ни дизайна, ни логики, ни даже единоначалия — кто попало добавляет что попало, а дыры потом затыкаются добавлением дополнительных элементов и слоев абстракции.
S>Условно: почему С-шный код делает не то, что ожидается, понять намного легче, чем почему пример из документации по QML выглядит совсем не так как ожидается, когда он скопирован в пользовательское окружение.
Потому что:
1. Язык С придумали тогда, когда сложность систем была околонулевой.
2. Там очень мало абстракций, и к тому же они довольно простые и очевидные, с интуитивным поведением. В том числе и потому, что у С, как ни странно, есть дизайн. А у этих всех DSL'ей только "что вышло, то вышло"
3. Если решать задачу высокого уровня на С, там будет столько кода, что его тоже будет не так просто понять.
Любой код пишется для машин, но читается людьми.