Комментарии 14
Забыли ссылку на свой ТГ-канал в конце поставить
Мне кажется, это слишком оптимистично. Область применения кодогенераторов уже сейчас на глазах уточняется и сужается до мелких-мелких утилиток.
Согласен. Скорее будут отдельные инструменты для отдельных IDE, систем, устройств и языков.
Из интересного читал, что на выставке MWC 2024 был концепт телефона без приложений от немецкой компании Deutsche Telekom. В их устройстве нет приложений, а всю работу выполняет искусственный интеллект. Например, ИИ сможет вызвать такси, перевести деньги, забронировать столик в ресторане и другое. Скорее всего, так как это концепт, он ещё очень сырой и не имеет всех нужных функций, но идея сама, а возможно даже подход представляются любопытными.
Мне кажется, что уже сейчас, при правильном подходе это все достижимо
Генерация типового кода типа контролер, entity, repository і т.д. працює на ура
Никто не мешает просить сгенерить код по схеме либо шаблону. Дальше написать бизнес логику - это даже приятно и быстро + поддержание ручного навыка кодинга
------------
Т.е. в целом да, все это уже есть, просто надо начать пользоваться
контролер, entity, repository і т.д
Это потому что у вас типовое (более чем) веб приложение. И то, бизнес логику свою вы модели доверять не собираетесь, как я вижу?
А у меня вот в приложении нет ни контроллеров, ни энтити, ни репозиториев - поэтому существующие модели его вообще написать не могут. Потому что такого кода в интернете нет или очень мало. Мне кажется, реальный прогресс в этой области будет тогда, когда я лично и быстро смогу обучить модель на моем коде, т.е. у меня будет не предобученная модель, которая умеет эти вот ваши веб приложения, а некая метамодель, которую я смогу обучить, не будучи специалистом в языковых моделях, скажем так. И которой можно будет объяснить, что вот такие конструкции - это неэффективно по памяти, например, или у них такие-то преимущества. И оно это будет учитывать при генерации, вместе с требованиями. До этого пока что далековато.
Ну да, но ведь и подход описывается для типовых (== массовых приложений). Понятно, что с нишевыми не очень
Обучать же модель - а смысл? Бизнес логика то разная. Тут как раз и проблема, так как шаблон скормить легко и он 99% рабочий. По сути тим лид через модель диктует правила "как надо"
Но в каждом проекте могут быть свои соглашения, поэтому эффективнее откатать типовое решение вручную, а потом скормить ИИ.
-------------------
Что касается архитектурных решений - ну такое, я не уверен, что это можно лекго переносить. Разве что как генерация примера. Описываешь задачу, получаешь пример и дальше его стягиваешь себе и допиливаешь напильником. Тут тоже все работает
Но у всех опыт разный
Ну бизнес логика скорее разная, но типовые решения в нишевых приложениях тоже встречаются. Я не настаиваю, я скорее оцениваю, в каком случае я бы мог для своих нетиповых приложений это все применить. И тут не хватает на первый взгляд именно обучаемости силами пользователя. Потому что буквально сейчас там и допиливать нечего.
До этого пока что далековато
Модели уже можно дообучать на своих данных, своей базой знаний или, например, внутренней кодовой базой, о которой вы говорите. (LoRA)
При желании и достаточном времени для обучения можно скармливать ей информацию и тем самым подстраивать её под себя, в том числе в таком виде:
можно будет объяснить, что вот такие конструкции - это неэффективно по памяти, например, или у них такие-то преимущества
Что такое LoRA? Мне только одна такая аббревиатура попадалась, и она не про модели и обучение.
Грубо говоря это создание пралаллельных слоёв к языковой модели, которые тоже участвуют в генерации ответа пользователю, при этом учитываются старые полученные знания модели. Вот этой вот надстройкой и может стать ваша база знаний. Хороший материал на эту тему видел тут
Будущее разработки программного обеспечения: переход от кодирования к естественному взаимодействию