Я её читал и вполне согласен с тем что там написано. Но вайб-кодинг это не единственный возможный сценарий применения ИИ в работе айтишника.
Копипастить выхлоп LLM не глядя можно до известного предела.
Момент с "получаешь рабочий результат, который надо только протестить. Но свой код тоже тестить надо" вы специально проигнорировали?
В синтаксисе регулярок ничего магического нет, надо один раз разобраться и использовать.
Зачем, если мне это нужно раз в сто лет?
А имена библиотек и функций из них уже давно обычные IDE умеют подсказывать, без всяких LLM
Всех существующих библиотек в мире? И где можно взять такую волшебную IDE?
LLM по спецификации OpenAPI сгегерирует стабы для тестов быстрее, чем генератор тестов (такой, к примеру)? Неправда, мягко говоря.
Он генерирует не пустые стабы, а уже с готовыми тестами, которые надо только проверить и подправить. Экономишь кучу времени, которое обычно нужно просто на то чтобы набивать текст.
Аргументы завершились, GPT не помог.
Вы не знаете что означает "котёнок с дверцей"? Ну давайте я вам это объясню: ваши аналогии просто не корректны и не подходят под обсуждаемый контекст.
Действительно, зачем? Однако зачем-то спорите.
Ну так не на конкретную тему, которая триггерит ваш фанатизм.
Вообще нет, ни капли не сложнее, просто больше машинного времени на сборку/развёртывание, но это делает глупая железяка, а не люди.
И например тестировать надо больше. И больше последствий при проблемах.
Я с вами абсолютно согласен, единственное, что я утверждаю, что этих ситуаций, где микросервисы лучше монолита, намного меньше, чем многим кажется.
У меня такой статистики нет. И по моему личному опыту большинство людей вообще не особо думают когда принимают такие решения. Кто-то из них просто принципиально за и поэтому пихает микросервисы везде где надо и где не надо. А кто-то принципиально против и выбирает монолит даже если это создаёт кучу проблем.
По сути дела, опросник по внедрению микросервисов должен выглядеть как-то так: Ваш электронный бизнес размером с Вайлдбериз? Нет? Значит, вам микросервисы пока ещё не нужны.
У нас вообще не электронный бизнес. Мы продаём решения для автоматизированных конвейрных линий для индустрии. Но всё равно вынуждены каждый второй проект делать на микросервисах.
И если вам это не принципиально, то это значит что всем остальным это тоже не принципиально?
А с микросервисами у меня будут зависимости на пять разных версий данной библиотеки
И в чём проблема? У вас же раздельная кодовая база. Можете хоть разные стеки использовать.
а потом ещё и вылезет разное побочное поведение из-за фрагментации версий
Ну так тестирование никто не отменял. Но вам нужно каждый микросервис тестировать отдельно. И если он работает, то его можно не трогать и не тестировать пока не нужно что-то менять конкретно в нём.
Наоборот, это будет делаться централизованно и контролируемо, ваши разработчики будут лишены возможности вот так с кондачка затянуть любую библиотеку, которая им понравилась, и будут вынуждены делать это осознанно.
То есть во первых у вас дополнительный организационный оверхед. Плюс если кому-то реально нужно аплейтить зависимости, то проблема остаётся.
Но случаев, когда в проект тянут команды с разными стеками просто потому, что всем пофигу, лишь бы работало, их куда больше, чем случаев, когда это делается реально вынужденно
Во первых хотелось бы посмотреть на эту статистику.
А во вторых даже если и так, то это тоже плюс для бизнеса. То есть он более свободен в вопросах найма новых сотрудников.
Если не пытаться смотреть на мир только сквозь окно промта LLM, таких примеров набирается вагон и тележка.
И каким образом это должно доказывать что от ИИ программистам вообще нет никакой пользы в их работе?
Маленький и ограниченный класс можно за минуту руками накидать. Хорошо, за две минуты можно. Это точно медленнее чем промпт сочинять?
Если не надо перед этим лезть и где-то искать как там правильно синтаксис у каких-нибудь регексов или там как правильно называются библиотеки или функции, которые ты последний раз использовал 100 лет назад.
А так копируешь кусок ТЗ и через 5 секунд получаешь рабочий результат, который надо только протестить. Но свой код тоже тестить надо.
Генерировать тесты (а не только стабы) для API научились задолго до появления LLM (вот, к примеру, вот, и еще много кто много где)
Но с ИИ это проще и быстрее.
Сломанные часы иногда (а если быть точным два раза в сутки) правильное время показывают. Это основание для того чтобы ими пользоваться как рабочими?
Котёнок с дверцей.
Человек может ошибиться один раз в год.
Люди разные бывают.
А любая LLM начинает галлюцинировать по мере "уплывания" контекста. И
Ну так не используйте её в ситуациях когда такое происходит. Кто вас заставляет то?
то ответ простой - если я научусь правильно выполнять повторяющиеся операции, ошибаться не буду.
Это не то о чём я вас спрашивал.
Ну и как бы мне ИИ не нужен чтобы выполнять одни и те же повторяющиеся операции с одинаковым результатом. Для этого другие инструменты есть.
Ну например если я знаю что какие-то люди когда-то мне обои в квартире приклеили так, что они через год от стенок отслаиваться стали, я у них по новой ремонт заказывать не буду.
Котёнок с дверцей.
В том что LLM хайп, фуфел, и финансовая пирамида. Хотите поспорить?
Зачем мне спорить с очередным фанатичным неолуддитом? Я просто буду использовать ИИ там, где это помогает мне в работе.
Масштабируемость у монолитов не особо и уступает микросервисам, вы точно так же можете добавлять инстансы по мере роста нагрузки
Но при этом в монолите вы не можете масштабировать конкретно ту часть системы, на которую выросла нагрузка. Вам нужно масштабировать всю систему.
Да и сложность обновлений, это сильно преувеличенная проблема.
Вам надо апдейтнуть какой-то небольшой функционал. У него есть зависимость от сторонней библиотеки и вам надо взять новую версию этой библиотеки. Но эта библиотека используется практически во всём монолите. Получается после небольшого апдейта вам надо тестировать практически весь функционал монолита.
И в случае микросервисов, и в случае монолита, от распределённых команд требуется одно и то же - соблюдение контрактов у компонент приложения.
Если у вас над одной монолитной кодовой базой работает 100500 человек, то вам будет очень весело согласовывать апдейты зависимостей или банально развлекаться с конфликтами в MR.
но следует упомянуть, что сама по себе ситуация, когда вы фрагментируете стек технологий в рамках одного проекта, это выстрел солью с перцем себе в жопу, и её надо избегать насколько это возможно
Как будто это всегда возможно. Ну то есть у нас половина проектов это интеграция решений от нескольких клиентов и их партнёров. Одни присылают сишные библиотеки, другие net core, третьи джаву, четвёртые питон, а интегрировать жто надо в какой-нибудь сименовский TIA, который до сих пор сидит на винформс или там в TestStand.
Так никто не говорит что монолит в принципе нельзя масштабировать.Но если у вас микросервисы, то можно масштабировать только ту часть сервиса, на которую растёт нагрузка. А вот нужно ли это конкретному продукту это уже отдельный вопрос.
Я обновляю его целиком, но да, не останавливая работу
И это гораздо сложнее и больше геморроя чем обновления в микросервисной архитектуре. Особенно если вам необходимо относительно часто делать относительно небольшие изменения.
Ещё раз: всё имеет свои плюсы и свои минусы. Микросервисы это не панацея и не серебряная пуля. Но в определённых ситуациях они лучше монолита.
Если я всё правильно помню, то где-то даже было исследование что именно содержание рекламы забывается относительно быстро, а "узнаваемость" бренда остаётся относительно долго.
То есть часто главное в рекламе именно выделиться на фоне остальных. И "скандальные" или даже "негативные" варианты часто справляются с этим лучше.
Даже на горизонте нескольких недель, а тем более месяцев, разработчики, которые заинтересованы в результате своей работы, а не только в том, чтобы выходцев из страны на букву И обогнать в скорости производства г-внокода, либо кратно сокращают ииспользование LLM, либо вообще от них отказываются.
Очень интересное утверждение, которое как минимум требует доказательства.
Да, вайб-кодинг не особо хорошо работает. Мягко говоря. Да, полноценный проект с нормальной архитектурой ИИ не в состоянии написать и уж тем более поддерживать.
Но есть куча способов применения, в том числе и для программистов, когда от него вполне себе есть польза. Банально как автодополнение отлично работает и кучу времени экономит. Маленькие и ограниченные классы, функции, сниппеты отлично пишет. Ошибки иногда быстро находит. Стабы для юнит-тестов генерирует. Или там документацию. И так далее и тому подобное.
В производстве галлюцинаций?
На данный момент в решении целого ряда простых задач.
Человек, обучившийся повторяющимся операциям, выполняет их далее без ошибок.
Неправда. Даже в такой ситуации люди иногда ошибаются.
Но опять же, это не отвечает на мой вопрос. Вы на него можете прямо ответить? Или нет?
Ну то есть рекламных обещаний вам достаточно?
То есть я проверю что в итоге получится и потом буду решать где и как я могу это использовать. А вы как-то по другому выбираете инструменты для работы?
Мне кто-то запретил свое мнение по поводу LLM высказывать?
Анекдот про машинистку, которая 1000 знаков в минуту может печатать, и что при этом получается на выходе,
И что этот анекдот должен доказывать или опровергать? Вы хотите доказать что ИИ абсолютно бесполезны? Мой опыт говорит об обратном. Что он не идеален? Ну так это естественно и нормальные люди это понимают.
ИИ это инструмент. Он имеет свои плюсы, минусы и ограничения. Любым инструментом надо уметь пользоваться.
Кстати сами создатели LLM всерьез размышляют как свои поделия заставить думать медленнее
И даже такие "замедленные" варианты скорее всего будут заметно быстрее человека.
Прример
Очень интересный пример, но он не отвечает на мой вопрос. Так что, если вас обучить на правильных источниках, вы перестанете ошибаться?
Кстати, а как вы себе этот специальный модуль представляете?
Никак. Мне в данном конкретном случае не особо интересно что там точно под капотом. Меня интересует сделает это мои инструменты лучше или нет.
Так что ли? А если она при проверке вместо того, чтобы убрать предыдущую галлюцинацию, новую поверх нее сгенерит?
Если вы ожидаете генеративный ИИ, который в 100% случаев даёт абсолютно правильный ответ, то скорее всего в обозримом будущем такого не будет. Но вас же никто не заставляет пользоваться ИИ. Живите без него. В чём проблема?
То есть грубо говоря ваш монолитный сервер запущен и работает. И вы не останавливая работу меняете отдельные части?
То есть я понимаю что в принципе это решаемо. Через какие-нибудь плагины или динамическую загрузку библиотек. Но на мой взгляд это всё тоже не особо просто, удобно и самое главное стабильно в рантайме.
Сначала нейросеть обучается на том, что ей подали на вход, то есть в том числе на справочниках и базах данных. В результате она на выходе генерирует галлюцинации, и идет проверять ответ в те же справочники и базы данных.
Точно так же как и люди. Только намного быстрее.
Одно непонятно - галлюцинации при таком раскладе откуда берутся?
Потому что ИИ, как и человек, не держит в памяти все справочники на которых обучалась.
Почему тогда ее сразу на правильных справочниках и базах данных не обучить?
Если вас на правильныз справочниках обучить, то вы никогда ошибаться не будете? Ну если не давать вам возможности проверить свои ответы прежде чем отвечать?
Есть одно хорошее правило, как решать описанную в вашей статье проблему: если в вашей архитектуре появилось множество вызывающих друг друга микросервисов, значит, вам пришла пора переходить на монолит
В монолите можно просто менять отдельные его части во время рантайма? Как насчёт вышеупомянутого масштабирования?
Не надо делать микросервисы просто ради того чтобы всё было стильно, модно и молодёжно. Микросервисы нужны когда требуются частые обновления и масштабируемость. Или например когда у вас над проектом работают большие разделённые команды с кучей разработчиков. Или когда по какой-то причине надо использовать разные технологии. Или например когда у вас данные по какой-то причине должны быть строго разделены(например из-за юридических требований). И так далее и тому подобное.
Ну по моему личному опыту перевести приложение с net462 на современный стэк оказалось не сильно сложнее чем перевести приложение с Java 8 на современный стэк.
Когда .NetCore только появился это было проблемой. Ну потому что практически все ходовые библиотеки и фрэймворки не были портированы. Сейчас это вполне себе работает.
Либо ИИ приносят вам какую-то пользу, которая больше требуемых расходов, и тогда вы платите. Либо нет и тогда вы отказываетесь от ИТ и живёте как раньше. В чём проблема?
Раньше это хорошо работало. Но примерно так с уже с год как минимум в половине известных мне саппортов это заканчивается тем что бот просто кладёт трубку.
"Некоторые вообще утверждают что она только мешает и ничем не страхует" - чушь
Она "мешает" тем что создаёт иллюзию безопасности. После чего отдельные люди просто перестают думать что откуда-то может прилететь эта самая NullReferenceException.
А они вполне себе могут прилететь. Особенно если работать со сторонними библиотеками или какими-то фрэймворками. В том же Prism например это вполне себе ещё проблема. Как минимум до 8-й версии включительно.
IDE сразу подсказывает где потенциально может быть NullReferenceException.
В том же WPF есть целый ряд ситуаций когда не подсказывает. Даже без Prism. В MAUI и Blazor, когда я пару лет назад последний раз с ними сталкивался это тоже совсем не идеально работало.
Иначе надо самому помнить и ловить такие места, и вот тут как раз забыть добавить где-то проверку проще простого
В том то и дело что их всё равно надо помнить и ловить. Надо меньше помнить и ловить, это да. Но всё равно надо.
То есть в целом фича полезная, но как минимум на данный момент не на 100% рабочая.
И вот на хабре уже появилось "поколение", которое не знает про "котёнка с дверцей"...
Я её читал и вполне согласен с тем что там написано. Но вайб-кодинг это не единственный возможный сценарий применения ИИ в работе айтишника.
Момент с "получаешь рабочий результат, который надо только протестить. Но свой код тоже тестить надо" вы специально проигнорировали?
Зачем, если мне это нужно раз в сто лет?
Всех существующих библиотек в мире? И где можно взять такую волшебную IDE?
Он генерирует не пустые стабы, а уже с готовыми тестами, которые надо только проверить и подправить. Экономишь кучу времени, которое обычно нужно просто на то чтобы набивать текст.
Вы не знаете что означает "котёнок с дверцей"? Ну давайте я вам это объясню: ваши аналогии просто не корректны и не подходят под обсуждаемый контекст.
Ну так не на конкретную тему, которая триггерит ваш фанатизм.
И например тестировать надо больше. И больше последствий при проблемах.
У меня такой статистики нет. И по моему личному опыту большинство людей вообще не особо думают когда принимают такие решения. Кто-то из них просто принципиально за и поэтому пихает микросервисы везде где надо и где не надо. А кто-то принципиально против и выбирает монолит даже если это создаёт кучу проблем.
У нас вообще не электронный бизнес. Мы продаём решения для автоматизированных конвейрных линий для индустрии. Но всё равно вынуждены каждый второй проект делать на микросервисах.
И если вам это не принципиально, то это значит что всем остальным это тоже не принципиально?
И в чём проблема? У вас же раздельная кодовая база. Можете хоть разные стеки использовать.
Ну так тестирование никто не отменял. Но вам нужно каждый микросервис тестировать отдельно. И если он работает, то его можно не трогать и не тестировать пока не нужно что-то менять конкретно в нём.
То есть во первых у вас дополнительный организационный оверхед. Плюс если кому-то реально нужно аплейтить зависимости, то проблема остаётся.
Во первых хотелось бы посмотреть на эту статистику.
А во вторых даже если и так, то это тоже плюс для бизнеса. То есть он более свободен в вопросах найма новых сотрудников.
И каким образом это должно доказывать что от ИИ программистам вообще нет никакой пользы в их работе?
Если не надо перед этим лезть и где-то искать как там правильно синтаксис у каких-нибудь регексов или там как правильно называются библиотеки или функции, которые ты последний раз использовал 100 лет назад.
А так копируешь кусок ТЗ и через 5 секунд получаешь рабочий результат, который надо только протестить. Но свой код тоже тестить надо.
Но с ИИ это проще и быстрее.
Котёнок с дверцей.
Люди разные бывают.
Ну так не используйте её в ситуациях когда такое происходит. Кто вас заставляет то?
Это не то о чём я вас спрашивал.
Ну и как бы мне ИИ не нужен чтобы выполнять одни и те же повторяющиеся операции с одинаковым результатом. Для этого другие инструменты есть.
Котёнок с дверцей.
Зачем мне спорить с очередным фанатичным неолуддитом? Я просто буду использовать ИИ там, где это помогает мне в работе.
Но при этом в монолите вы не можете масштабировать конкретно ту часть системы, на которую выросла нагрузка. Вам нужно масштабировать всю систему.
Вам надо апдейтнуть какой-то небольшой функционал. У него есть зависимость от сторонней библиотеки и вам надо взять новую версию этой библиотеки. Но эта библиотека используется практически во всём монолите. Получается после небольшого апдейта вам надо тестировать практически весь функционал монолита.
Если у вас над одной монолитной кодовой базой работает 100500 человек, то вам будет очень весело согласовывать апдейты зависимостей или банально развлекаться с конфликтами в MR.
Как будто это всегда возможно. Ну то есть у нас половина проектов это интеграция решений от нескольких клиентов и их партнёров. Одни присылают сишные библиотеки, другие net core, третьи джаву, четвёртые питон, а интегрировать жто надо в какой-нибудь сименовский TIA, который до сих пор сидит на винформс или там в TestStand.
Так никто не говорит что монолит в принципе нельзя масштабировать.Но если у вас микросервисы, то можно масштабировать только ту часть сервиса, на которую растёт нагрузка. А вот нужно ли это конкретному продукту это уже отдельный вопрос.
И это гораздо сложнее и больше геморроя чем обновления в микросервисной архитектуре. Особенно если вам необходимо относительно часто делать относительно небольшие изменения.
Ещё раз: всё имеет свои плюсы и свои минусы. Микросервисы это не панацея и не серебряная пуля. Но в определённых ситуациях они лучше монолита.
Реклама это скорее про запоминаемость.
Если я всё правильно помню, то где-то даже было исследование что именно содержание рекламы забывается относительно быстро, а "узнаваемость" бренда остаётся относительно долго.
То есть часто главное в рекламе именно выделиться на фоне остальных.
И "скандальные" или даже "негативные" варианты часто справляются с этим лучше.
Очень интересное утверждение, которое как минимум требует доказательства.
Да, вайб-кодинг не особо хорошо работает. Мягко говоря. Да, полноценный проект с нормальной архитектурой ИИ не в состоянии написать и уж тем более поддерживать.
Но есть куча способов применения, в том числе и для программистов, когда от него вполне себе есть польза. Банально как автодополнение отлично работает и кучу времени экономит. Маленькие и ограниченные классы, функции, сниппеты отлично пишет. Ошибки иногда быстро находит. Стабы для юнит-тестов генерирует. Или там документацию. И так далее и тому подобное.
На данный момент в решении целого ряда простых задач.
Неправда. Даже в такой ситуации люди иногда ошибаются.
Но опять же, это не отвечает на мой вопрос. Вы на него можете прямо ответить? Или нет?
То есть я проверю что в итоге получится и потом буду решать где и как я могу это использовать. А вы как-то по другому выбираете инструменты для работы?
И в чём оно заключается то?
И что этот анекдот должен доказывать или опровергать? Вы хотите доказать что ИИ абсолютно бесполезны? Мой опыт говорит об обратном. Что он не идеален? Ну так это естественно и нормальные люди это понимают.
ИИ это инструмент. Он имеет свои плюсы, минусы и ограничения. Любым инструментом надо уметь пользоваться.
И даже такие "замедленные" варианты скорее всего будут заметно быстрее человека.
Очень интересный пример, но он не отвечает на мой вопрос. Так что, если вас обучить на правильных источниках, вы перестанете ошибаться?
Никак. Мне в данном конкретном случае не особо интересно что там точно под капотом. Меня интересует сделает это мои инструменты лучше или нет.
Если вы ожидаете генеративный ИИ, который в 100% случаев даёт абсолютно правильный ответ, то скорее всего в обозримом будущем такого не будет. Но вас же никто не заставляет пользоваться ИИ. Живите без него. В чём проблема?
То есть грубо говоря ваш монолитный сервер запущен и работает. И вы не останавливая работу меняете отдельные части?
То есть я понимаю что в принципе это решаемо. Через какие-нибудь плагины или динамическую загрузку библиотек. Но на мой взгляд это всё тоже не особо просто, удобно и самое главное стабильно в рантайме.
Точно так же как и люди. Только намного быстрее.
Потому что ИИ, как и человек, не держит в памяти все справочники на которых обучалась.
Если вас на правильныз справочниках обучить, то вы никогда ошибаться не будете? Ну если не давать вам возможности проверить свои ответы прежде чем отвечать?
В монолите можно просто менять отдельные его части во время рантайма? Как насчёт вышеупомянутого масштабирования?
Не надо делать микросервисы просто ради того чтобы всё было стильно, модно и молодёжно. Микросервисы нужны когда требуются частые обновления и масштабируемость. Или например когда у вас над проектом работают большие разделённые команды с кучей разработчиков. Или когда по какой-то причине надо использовать разные технологии. Или например когда у вас данные по какой-то причине должны быть строго разделены(например из-за юридических требований). И так далее и тому подобное.
Ну по моему личному опыту перевести приложение с net462 на современный стэк оказалось не сильно сложнее чем перевести приложение с Java 8 на современный стэк.
Когда .NetCore только появился это было проблемой. Ну потому что практически все ходовые библиотеки и фрэймворки не были портированы. Сейчас это вполне себе работает.
Что значит "подсядем"? Это же не наркотик.
Либо ИИ приносят вам какую-то пользу, которая больше требуемых расходов, и тогда вы платите. Либо нет и тогда вы отказываетесь от ИТ и живёте как раньше. В чём проблема?
Потому что тогда надо как минимум знать в какой конкретно справочник надо смотреть и где его найти.
И средний человек не настолько хорошо разбирается во всех интересующих его темах чтобы всё это знать наизусть.
И даже если ты знаешь какие справочники тебе нужны, то даже в такой ситуации ИИ часто может гораздо быстрее сделать выборку нужной тебе информации.
Раньше это хорошо работало. Но примерно так с уже с год как минимум в половине известных мне саппортов это заканчивается тем что бот просто кладёт трубку.
До тех пор пока другие страны не решат начать вводить "дигитальные пошлины" на американские сервисы в ответ на торговые пошлины США.
Тот же ЕС например вполне себе такой вариант рассматривал. И насколько я знаю не они одни.
Она "мешает" тем что создаёт иллюзию безопасности. После чего отдельные люди просто перестают думать что откуда-то может прилететь эта самая NullReferenceException.
А они вполне себе могут прилететь. Особенно если работать со сторонними библиотеками или какими-то фрэймворками. В том же Prism например это вполне себе ещё проблема. Как минимум до 8-й версии включительно.
В том же WPF есть целый ряд ситуаций когда не подсказывает. Даже без Prism. В MAUI и Blazor, когда я пару лет назад последний раз с ними сталкивался это тоже совсем не идеально работало.
В том то и дело что их всё равно надо помнить и ловить. Надо меньше помнить и ловить, это да. Но всё равно надо.
То есть в целом фича полезная, но как минимум на данный момент не на 100% рабочая.