Да, бывает такая специфика. Я в IoT с этим сталкивался. Там протоколы и библиотеки взаимодействия с железяками гвоздями прибиты к производителям этих железяк.
Но, такая ситуация в отдельно взятых отраслях это скорее исключение из правила, чем правило. Просто эти отрасли не сумели перестроиться на более эффективный формат доставки ценности.
А теперь представьте, что в этой либе есть ещё один баг, который ваш LLM не заметил.
Если бы вы завели issue автору на починку бага, то он бы починил его и для вас, и для всех остальных пользователей либы. И тогда, вполне вероятно, кто нибудь заметил бы баг, который не заметили вы. И так же завёл бы issue. Соответственно починка второго бага стала бы для вас бесплатной.
А переписав либу вы взвалили на себя стоимость долгосрочной поддержки этой либы. Что вас не ускоряет, а замедляет.
Здесь вы описали сценарий ночного кошмара пользователей vendor lock-in решений. Такая библиотека становится не вашим активом, а вашим пассивом. Техническим долгом. Расплатиться по которому рано или поздно придётся. И плата по этому долгу может в разы превышать стоимость разработки вашего проекта.
Именно этот сценарий стал причиной появления открытых open source решений.
Зачем качать библиотеку, если можно сгенерировать полностью схожую и не связываться с лицензиями и прочими сложными вопросами? Тебе это все становится не нужно.
Мысль интересная, но пока она бьется об одну важную стену. Стена называется "LLM генерит говнокод". Говнокод не в плане, красивый он или некрасивый, а в плане, что он неработоспособный. А скажешь агенту "вот бага, подправь" - он часто сделает еще хуже.
Попробуйте взглянуть на это с другой, немного парадоксальной стороны. Стоимость кода просто физически не может упасть, потому что код сам по себе ровным счётом ничего не стоит. Его стоимость и до появления ИИ равнялась нулю, и после появления ИИ так же равняется нулю - так как ноль, умноженный на 10 равен нулю.
Почему стоимость кода равна нулю? Представьте, что у вас есть 2 разные библиотеки, которые решают одну и ту же задачу. Обе библиотеки работают одинаково корректно, но, одна библиотека заброшена несколько лет назад, а вокруг второй сформировалось сообщество разработчиков, которое активно развивает и поддерживает библиотеку. Какую библиотеку вы выберете? Конечно вторую. Более того, даже если бы второй библиотеки не существовало, вы бы всё равно в боевой проект не подключили бы первую. А почему? Да потому что вам важен не просто код, который решает задачу, а гарантированно верное решение, которое со временем не утратит свою актуальность, несмотря на выход новых версий языков и сопутствующих библиотек. Более того, вам важна уверенность в том, что если в решении найдётся ошибка, то она будет исправлена. Т.е. получается, что второе решение обладает для вас ценностью не потому, что оно работает, а потому, что его поддерживает сообщество инженеров. Т.е. ценностью обладает не код, а техническая экспертиза инженеров, которые его развивают и поддерживают.
Хорошо, а может ли результат работы LLM представлять для меня такую же ценность, как техническая экспертиза сообщества? Предположим, я подробно описал решение в виде спецификации и сгенерировал по ней код. Вышли новые версии языков/библиотек - перегенерировал. Нашлась ошибка - снова перегенерировал. Что здесь не так? А то, что LLM не обеспечивает строго детерменированную кодогенерацию, и не несёт ответственности (даже репутационной) за результат своей работы. Результат кодогенерации может содержать некоторое множество ошибок. Результат повторной кодогенерации по той же спеке и с тем же набором версий языков/библиотек может содержать другое множество ошибок, не равное первому. Как обеспечить гарантию качества кодогенерации? Да только если вы самостоятельно проведёте качественное ревью кода и обеспечите полноценное тестирование результата. Т.е. если вы проинвестируете в результат кодогенерации LLM своё рабочее время и свою техническую экспертизу.
Так чем же отличается результат кодогенерации LLM от первой, неподдерживаемой библиотеки? Да ничем! И там и там вы вынуждены будете инвестировать своё время и свою техническую экспертизу в долгосрочную поддержку полученного решения. Соответственно результат кодогенерации LLM для вас ничем не выгоднее, чем неподдерживаемая библиотека.
Т.е. чем ценна скачанная Open Source библиотека? Кодом? Нет, не кодом! А ценна она поддержкой сообщества, которое инвестирует своё время и техническую экспертизу в поддержку этого решения. И которому вы делегируете свою ответственность за долгосрочную стабильность и корректность этого решения.
Ну, на этом проекте джун не взлетит. А на проекте попроще - почему нет? Только джун нужен мотивированный и с хорошим техническим образованием, а не выпускник курсов. Чтобы системное мышление и навык обучения новому были развиты.
А запустили этот проект 2 человека. Один наполовину архитектор, наполовину разработчик. Другой наполовину девопс, наполовину разработчик. Ну и ИИ'шка, которой в основном тесты генерировали. Так как с жёстким хайлоадом и многопоточностью она не справляется. Куда уж меньше то?
Я сейчас такой лид :) И, с учётом масштаба проекта, моего "контекстного окна" катастрофически не хватает, чтобы уследить за всем. Поэтому единственный выход для меня - делегировать. А кому делегировать? Можно конечно сеньёру. Но попробуй его ещё найди, даже сейчас. И попробуй ещё с ним договориться - порой непросто бывает.
Так что для меня зачастую проще бывает взять мидла, и вырастить из него сеньёра "под себя".
Да, согласен. За свою карьеру я видел массу мёртворождённых проектов. Когда с самого начала очевидно, что проект ни о чём, и никакой пользы не принесёт. В ковидные годы их особенно много появилось. А сейчас, когда кредиты подорожали, бизнес конечно прикрывает такие проекты, и сокращает команды. Типичный кризис перепроизводства. Остаётся только надеяться, что в среднесрочной перспективе этот кризис оздоровит отрасль.
Видел конечно :) Написать сложно может любой дурак. А вот создать простое, понятное и легко читаемое решение сложной проблемы - это настоящее искусство.
ИИ кратно умножает и сильные и слабые стороны инженера. А вот представьте теперь себе такой "звёздный" код, умноженный с помощью ИИ :)
меряться пиписками - скучно. Я в разработке с 1980го, и - что?
Т.е. из всего моего поста вы увидели только упоминание об опыте работы и восприняли это как призыв "померяться пиписьками"? Очень грустно. И очень странно. Никогда бы не подумал, что мои высказывания можно так неадекватно интерпретировать.
Да, мы явно друг друга не понимаем. И это сулит и отрасли и бизнесу очень большие проблемы. Ну и как следствие, для меня это тоже может стать проблемой. И для вас тоже - несмотря на всю вашу самоуверенность.
В том то и дело, что видел их и до ИИ. И, боюсь себе даже представить, что будет, когда безответственные люди отпустят поводья, и начнут всё генерировать с помощью ИИ, проводя ревью по диагонали. И теряя постепенно техническую квалификацию и снижая тем самым качество ревью.
PS
И, на всякий случай. Не надо на меня вешать лейбл противника ИИ. Для меня это просто ещё один инструмент в моём арсенале. Как можно быть противником тяпки или лопаты? Просто не надо лопатой полоть сорняки а тяпкой вскапывать огород. Вот и всё.
Ну а я видел реальные инциденты и сбои на проде. Случаи потерь данных. Уязвимости с точки зрения безопасности. Проблемы с производительностью - и с пропускной способностью и со временем отклика. Видел архитектурные проблемы, из за которых невозможно было обеспечить горизонтальную масштабируемость. Видел гонки в многопоточных решениях и утечки памяти и ресурсов.
И всё это я видел на решениях, где архитектура и качество кода по моим оценкам были на топ уровне.
У нас просто немного разный опыт. Вам дали таблетки от головной боли, таблетки от проблем с пищеварением и жаропонижающее. И вы говорите - ну а зачем мне теперь врачи? А я, как "практикующий хирург", видел такие кейсы, которые вы себе даже представить не можете.
На лицо классический эффект Даннинга — Крюгера. Когда безграмотность порождает самоуверенность.
А дальше 2036 год, когда уголь = цене подписки, а Паровую машину человек создаёт сам, наговаривая промпт ассистенту ИИ на телефоне.
Ну или когда бизнес из за стремительной недетерменированной кодогенерации накопил такой техдолг, при котором денежные потери от инцидентов начали в сотни раз превышать экономию от ускорения разработки... ;)
Сделать с нуля - это самое простое. А вы сможете со своим пайплайном обеспечить долгосрочное развитие и эксплуатацию решения? Закрывать инциденты? Искать причины сбоев? Решать проблемы производительности? Обеспечивать отказоустойчивость? Закрывать новые потребности бизнеса?
А когда вы уволитесь (а вы ведь рано или поздно уволитесь), бизнес сможет найти инженера, который продолжит ваше дело?
Мне кажется, что вы не до конца поняли мою аргументацию.
Попробую по другому объяснить. Я в разработке с 1999 года. По сравнению с теми временами эффективность разработки выросла в десятки раз и безо всякого ИИ. Но, работы при этом не стало меньше. Наоборот. Её стало гораздо больше. И денег в отрасли стало гораздо больше. Те зарплаты, которые сейчас джуны и мидлы получают, тогда были чем то из области фантастики (зарплата на моём первом месте работы была примерно 150 долларов Т.е. в районе 20 тыров по нынешним деньгам. На втором месте работы - 400 долларов. Это когда я уже крепкий мидл был).
А почему? Помните, вы в статье приводили пример с углём и паровыми машинами? Когда эффективность паровых машин только повысила спрос на уголь?
Но, углём вы почему-то считаете код ну или ваш пайплайн, который в 10 раз быстрее генерирует код. И в этом ваша главная ошибка. Код - это не уголь. Это шлак. Стоимость шлака равна нулю. Ноль, умноженный на 10, равен нулю.
Уголь в IT-шной паровой машине - это инженер. Который с помощью целого набора разнородных инструментов (код один из них) создаёт и развивает средства автоматизации бизнес процессов.
И, большая просьба, не путать инженеров с кодерами, которые наводнили рынок. Кодер - это не инженер. Это имитация инженера. Кодеров бизнес начал покупать только из за отчаяния, так как инженеров катастрофически не хватало. И вот кодерам действительно придётся туго.
Написано действительно красиво, и очень убедительно. В первый момент после прочтения я согласился со всеми выводами статьи. Но, какой то червячёк сомнения остался. Я привык доверять своей интуиции, и начал думать - что здесь не так?
А "не так" в следующем. Жизненный цикл статьи и программного обеспечения имеет радикальные различия.
Готовая статья - это уже продукт, который можно продавать. Как футболку или пончик. Красивая и качественная футболка? Продастся! Нет? До свидания! Невкусный пончик? До свидания!
А готовое ПО не стоит ровным счётом ничего. И работающий код сам по себе не стоит ровным счётом ничего. Это, кстати, и до появления ИИ так было. Почему? Да потому что бизнес или пользователь покупают не ПО, в котором ничего не понимают, а средство автоматизации некоторого бизнес процесса. А бизнес процесс может существовать годами или даже десятилетиями. И, годами или десятилетиями, он должн работать стабильно. Более того. Бизнес процесс это сущность нестатичная. Он постоянно развивается и меняется. Эволюционирует. И средство автоматизации (тобишь ПО), должно развиваться и меняться ВМЕСТЕ с бизнес процессом. И оставаться при этом ПРЕДСКАЗУЕМО стабильным. Потому что нестабильность средства автоматизации стоит бизнесу ОЧЕНЬ дорого.
Поэтому бизнес покупает не строчки кода и не ПО. Он покупает техническую экспертизу инженера, который создаёт и в долгосрочной перспективе развивает средство автоматизации, обеспечивая стабильность бизнеса.
А какими инструментами инженер при этом пользуется - бизнесу не важно. Накодил руками? Молодец! Подключил кучу библиотек и фреймворков, чтобы писать быстрее и дешевле? Большой молодец! Ещё больше ускорился с помощью ИИ? Умница детка!
Бизнесу главное вменяемая стоимость, разумные сроки разраразработки и предсказуемая долгосрочная стабильность средства автоматизации. А чем при этом инженер пользуется - кодом, библиотеками, ИИ или шаманским бубном, бизнесу до лампочки.
Да, так тоже, к сожалению бывает. Значит у вас просто не было другого выхода.
Да, бывает такая специфика. Я в IoT с этим сталкивался. Там протоколы и библиотеки взаимодействия с железяками гвоздями прибиты к производителям этих железяк.
Но, такая ситуация в отдельно взятых отраслях это скорее исключение из правила, чем правило. Просто эти отрасли не сумели перестроиться на более эффективный формат доставки ценности.
А теперь представьте, что в этой либе есть ещё один баг, который ваш LLM не заметил.
Если бы вы завели issue автору на починку бага, то он бы починил его и для вас, и для всех остальных пользователей либы. И тогда, вполне вероятно, кто нибудь заметил бы баг, который не заметили вы. И так же завёл бы issue. Соответственно починка второго бага стала бы для вас бесплатной.
А переписав либу вы взвалили на себя стоимость долгосрочной поддержки этой либы. Что вас не ускоряет, а замедляет.
Здесь вы описали сценарий ночного кошмара пользователей vendor lock-in решений. Такая библиотека становится не вашим активом, а вашим пассивом. Техническим долгом. Расплатиться по которому рано или поздно придётся. И плата по этому долгу может в разы превышать стоимость разработки вашего проекта.
Именно этот сценарий стал причиной появления открытых open source решений.
Попробуйте взглянуть на это с другой, немного парадоксальной стороны. Стоимость кода просто физически не может упасть, потому что код сам по себе ровным счётом ничего не стоит. Его стоимость и до появления ИИ равнялась нулю, и после появления ИИ так же равняется нулю - так как ноль, умноженный на 10 равен нулю.
Почему стоимость кода равна нулю? Представьте, что у вас есть 2 разные библиотеки, которые решают одну и ту же задачу. Обе библиотеки работают одинаково корректно, но, одна библиотека заброшена несколько лет назад, а вокруг второй сформировалось сообщество разработчиков, которое активно развивает и поддерживает библиотеку. Какую библиотеку вы выберете? Конечно вторую. Более того, даже если бы второй библиотеки не существовало, вы бы всё равно в боевой проект не подключили бы первую. А почему? Да потому что вам важен не просто код, который решает задачу, а гарантированно верное решение, которое со временем не утратит свою актуальность, несмотря на выход новых версий языков и сопутствующих библиотек. Более того, вам важна уверенность в том, что если в решении найдётся ошибка, то она будет исправлена. Т.е. получается, что второе решение обладает для вас ценностью не потому, что оно работает, а потому, что его поддерживает сообщество инженеров. Т.е. ценностью обладает не код, а техническая экспертиза инженеров, которые его развивают и поддерживают.
Хорошо, а может ли результат работы LLM представлять для меня такую же ценность, как техническая экспертиза сообщества? Предположим, я подробно описал решение в виде спецификации и сгенерировал по ней код. Вышли новые версии языков/библиотек - перегенерировал. Нашлась ошибка - снова перегенерировал. Что здесь не так? А то, что LLM не обеспечивает строго детерменированную кодогенерацию, и не несёт ответственности (даже репутационной) за результат своей работы. Результат кодогенерации может содержать некоторое множество ошибок. Результат повторной кодогенерации по той же спеке и с тем же набором версий языков/библиотек может содержать другое множество ошибок, не равное первому. Как обеспечить гарантию качества кодогенерации? Да только если вы самостоятельно проведёте качественное ревью кода и обеспечите полноценное тестирование результата. Т.е. если вы проинвестируете в результат кодогенерации LLM своё рабочее время и свою техническую экспертизу.
Так чем же отличается результат кодогенерации LLM от первой, неподдерживаемой библиотеки? Да ничем! И там и там вы вынуждены будете инвестировать своё время и свою техническую экспертизу в долгосрочную поддержку полученного решения. Соответственно результат кодогенерации LLM для вас ничем не выгоднее, чем неподдерживаемая библиотека.
Т.е. чем ценна скачанная Open Source библиотека? Кодом? Нет, не кодом! А ценна она поддержкой сообщества, которое инвестирует своё время и техническую экспертизу в поддержку этого решения. И которому вы делегируете свою ответственность за долгосрочную стабильность и корректность этого решения.
Ну, на этом проекте джун не взлетит. А на проекте попроще - почему нет? Только джун нужен мотивированный и с хорошим техническим образованием, а не выпускник курсов. Чтобы системное мышление и навык обучения новому были развиты.
А запустили этот проект 2 человека. Один наполовину архитектор, наполовину разработчик. Другой наполовину девопс, наполовину разработчик. Ну и ИИ'шка, которой в основном тесты генерировали. Так как с жёстким хайлоадом и многопоточностью она не справляется. Куда уж меньше то?
Я сейчас такой лид :) И, с учётом масштаба проекта, моего "контекстного окна" катастрофически не хватает, чтобы уследить за всем. Поэтому единственный выход для меня - делегировать. А кому делегировать? Можно конечно сеньёру. Но попробуй его ещё найди, даже сейчас. И попробуй ещё с ним договориться - порой непросто бывает.
Так что для меня зачастую проще бывает взять мидла, и вырастить из него сеньёра "под себя".
То "пиписьки", то "передёрнули". Извините, я не могу общаться в таком стиле. Это уровень школьников младших классов. Я давно вышел из этого возраста.
Да, согласен. За свою карьеру я видел массу мёртворождённых проектов. Когда с самого начала очевидно, что проект ни о чём, и никакой пользы не принесёт. В ковидные годы их особенно много появилось. А сейчас, когда кредиты подорожали, бизнес конечно прикрывает такие проекты, и сокращает команды. Типичный кризис перепроизводства. Остаётся только надеяться, что в среднесрочной перспективе этот кризис оздоровит отрасль.
Видел конечно :) Написать сложно может любой дурак. А вот создать простое, понятное и легко читаемое решение сложной проблемы - это настоящее искусство.
ИИ кратно умножает и сильные и слабые стороны инженера. А вот представьте теперь себе такой "звёздный" код, умноженный с помощью ИИ :)
Т.е. из всего моего поста вы увидели только упоминание об опыте работы и восприняли это как призыв "померяться пиписьками"? Очень грустно. И очень странно. Никогда бы не подумал, что мои высказывания можно так неадекватно интерпретировать.
Да, мы явно друг друга не понимаем. И это сулит и отрасли и бизнесу очень большие проблемы. Ну и как следствие, для меня это тоже может стать проблемой. И для вас тоже - несмотря на всю вашу самоуверенность.
В том то и дело, что видел их и до ИИ. И, боюсь себе даже представить, что будет, когда безответственные люди отпустят поводья, и начнут всё генерировать с помощью ИИ, проводя ревью по диагонали. И теряя постепенно техническую квалификацию и снижая тем самым качество ревью.
PS
И, на всякий случай. Не надо на меня вешать лейбл противника ИИ. Для меня это просто ещё один инструмент в моём арсенале. Как можно быть противником тяпки или лопаты? Просто не надо лопатой полоть сорняки а тяпкой вскапывать огород. Вот и всё.
Ну а я видел реальные инциденты и сбои на проде. Случаи потерь данных. Уязвимости с точки зрения безопасности. Проблемы с производительностью - и с пропускной способностью и со временем отклика. Видел архитектурные проблемы, из за которых невозможно было обеспечить горизонтальную масштабируемость. Видел гонки в многопоточных решениях и утечки памяти и ресурсов.
И всё это я видел на решениях, где архитектура и качество кода по моим оценкам были на топ уровне.
У нас просто немного разный опыт. Вам дали таблетки от головной боли, таблетки от проблем с пищеварением и жаропонижающее. И вы говорите - ну а зачем мне теперь врачи? А я, как "практикующий хирург", видел такие кейсы, которые вы себе даже представить не можете.
На лицо классический эффект Даннинга — Крюгера. Когда безграмотность порождает самоуверенность.
Ну или когда бизнес из за стремительной недетерменированной кодогенерации накопил такой техдолг, при котором денежные потери от инцидентов начали в сотни раз превышать экономию от ускорения разработки... ;)
Да, есть такой момент. Согласен. В среднесрочной перспективе огребать будут все. Пока рынок найма не адаптируется к изменениям.
Сделать с нуля - это самое простое. А вы сможете со своим пайплайном обеспечить долгосрочное развитие и эксплуатацию решения? Закрывать инциденты? Искать причины сбоев? Решать проблемы производительности? Обеспечивать отказоустойчивость? Закрывать новые потребности бизнеса?
А когда вы уволитесь (а вы ведь рано или поздно уволитесь), бизнес сможет найти инженера, который продолжит ваше дело?
Мне кажется, что вы не до конца поняли мою аргументацию.
Попробую по другому объяснить. Я в разработке с 1999 года. По сравнению с теми временами эффективность разработки выросла в десятки раз и безо всякого ИИ. Но, работы при этом не стало меньше. Наоборот. Её стало гораздо больше. И денег в отрасли стало гораздо больше. Те зарплаты, которые сейчас джуны и мидлы получают, тогда были чем то из области фантастики (зарплата на моём первом месте работы была примерно 150 долларов Т.е. в районе 20 тыров по нынешним деньгам. На втором месте работы - 400 долларов. Это когда я уже крепкий мидл был).
А почему? Помните, вы в статье приводили пример с углём и паровыми машинами? Когда эффективность паровых машин только повысила спрос на уголь?
Но, углём вы почему-то считаете код ну или ваш пайплайн, который в 10 раз быстрее генерирует код. И в этом ваша главная ошибка. Код - это не уголь. Это шлак. Стоимость шлака равна нулю. Ноль, умноженный на 10, равен нулю.
Уголь в IT-шной паровой машине - это инженер. Который с помощью целого набора разнородных инструментов (код один из них) создаёт и развивает средства автоматизации бизнес процессов.
И, большая просьба, не путать инженеров с кодерами, которые наводнили рынок. Кодер - это не инженер. Это имитация инженера. Кодеров бизнес начал покупать только из за отчаяния, так как инженеров катастрофически не хватало. И вот кодерам действительно придётся туго.
Написано действительно красиво, и очень убедительно. В первый момент после прочтения я согласился со всеми выводами статьи. Но, какой то червячёк сомнения остался. Я привык доверять своей интуиции, и начал думать - что здесь не так?
А "не так" в следующем. Жизненный цикл статьи и программного обеспечения имеет радикальные различия.
Готовая статья - это уже продукт, который можно продавать. Как футболку или пончик. Красивая и качественная футболка? Продастся! Нет? До свидания! Невкусный пончик? До свидания!
А готовое ПО не стоит ровным счётом ничего. И работающий код сам по себе не стоит ровным счётом ничего. Это, кстати, и до появления ИИ так было. Почему? Да потому что бизнес или пользователь покупают не ПО, в котором ничего не понимают, а средство автоматизации некоторого бизнес процесса. А бизнес процесс может существовать годами или даже десятилетиями. И, годами или десятилетиями, он должн работать стабильно. Более того. Бизнес процесс это сущность нестатичная. Он постоянно развивается и меняется. Эволюционирует. И средство автоматизации (тобишь ПО), должно развиваться и меняться ВМЕСТЕ с бизнес процессом. И оставаться при этом ПРЕДСКАЗУЕМО стабильным. Потому что нестабильность средства автоматизации стоит бизнесу ОЧЕНЬ дорого.
Поэтому бизнес покупает не строчки кода и не ПО. Он покупает техническую экспертизу инженера, который создаёт и в долгосрочной перспективе развивает средство автоматизации, обеспечивая стабильность бизнеса.
А какими инструментами инженер при этом пользуется - бизнесу не важно. Накодил руками? Молодец! Подключил кучу библиотек и фреймворков, чтобы писать быстрее и дешевле? Большой молодец! Ещё больше ускорился с помощью ИИ? Умница детка!
Бизнесу главное вменяемая стоимость, разумные сроки разраразработки и предсказуемая долгосрочная стабильность средства автоматизации. А чем при этом инженер пользуется - кодом, библиотеками, ИИ или шаманским бубном, бизнесу до лампочки.