Что значит добавить идемпотентность в API создания заказа? Это значит, что в сам API необходимо добавить возможность передачи ключа идемпотентности, внедрить бизнес логику идемпотентного потребителя в сервис, реализующий API - доработать схему БД и/или кеши для хранения ключа идемпотентности, обеспечить корректную миграцию схемы БД и данных на проде, доработать оркестрацию/хореографию микросервисов вашей платформы для обеспечения передачи ключа идемпотентности по всей цепочке вызовов, решить проблему распределенного состояния гонки при сохранении ключа, проблему частичных отказов в распределённых транзакциях, внедрить механизм проверки ключа, обеспечить детерминированность ответов, обеспечить защиту бизнес логики идемпотентности от атак злоумышленников (например когда вам с одним и тем же ключём передают разные суммы). Со стороны потребителя идемпотентного API обеспечить корректную генерацию ключей идемпотентности и внедрить механизм retry'ев, проработать стратегию балансировки повторных запросов к идемпотентному API (Failover Routing, Retry Control, Exponential Backoff, Circuit Breaker, Retry Budgets).
По сути это гигантская архитектурная задача, затрагивающая все аспекты жизнедеятельности и все архитектурные слои вашей платформы. И вы эту задачу делегируете ИИ простым промптом из 5 слов?
Так какими же качествами должен обладать разработчик версии 2.0? Прежде всего развитой инженерной культурой, знанием и пониманием современных архитектурных паттернов, пониманием всех аспектов работы разрабатываемой платформы (а не только своего участка), доскональным пониманием бизнес логики, пониманием процессов внедрения изменений и решения инцидентов, развитой инженерной ответственностью.
А все тактические приёмы, которые вы описали в своей статье находятся даже не на втором, а на 10м месте. Единственный плюс этих приёмов состоит в том, что при отсутствии инженерной культуры вы раньше зафейлитесь, и бизнес потеряет меньше денег.
Да, бывает такая специфика. Я в IoT с этим сталкивался. Там протоколы и библиотеки взаимодействия с железяками гвоздями прибиты к производителям этих железяк.
Но, такая ситуация в отдельно взятых отраслях это скорее исключение из правила, чем правило. Просто эти отрасли не сумели перестроиться на более эффективный формат доставки ценности.
А теперь представьте, что в этой либе есть ещё один баг, который ваш LLM не заметил.
Если бы вы завели issue автору на починку бага, то он бы починил его и для вас, и для всех остальных пользователей либы. И тогда, вполне вероятно, кто нибудь заметил бы баг, который не заметили вы. И так же завёл бы issue. Соответственно починка второго бага стала бы для вас бесплатной.
А переписав либу вы взвалили на себя стоимость долгосрочной поддержки этой либы. Что вас не ускоряет, а замедляет.
Здесь вы описали сценарий ночного кошмара пользователей vendor lock-in решений. Такая библиотека становится не вашим активом, а вашим пассивом. Техническим долгом. Расплатиться по которому рано или поздно придётся. И плата по этому долгу может в разы превышать стоимость разработки вашего проекта.
Именно этот сценарий стал причиной появления открытых open source решений.
Зачем качать библиотеку, если можно сгенерировать полностью схожую и не связываться с лицензиями и прочими сложными вопросами? Тебе это все становится не нужно.
Мысль интересная, но пока она бьется об одну важную стену. Стена называется "LLM генерит говнокод". Говнокод не в плане, красивый он или некрасивый, а в плане, что он неработоспособный. А скажешь агенту "вот бага, подправь" - он часто сделает еще хуже.
Попробуйте взглянуть на это с другой, немного парадоксальной стороны. Стоимость кода просто физически не может упасть, потому что код сам по себе ровным счётом ничего не стоит. Его стоимость и до появления ИИ равнялась нулю, и после появления ИИ так же равняется нулю - так как ноль, умноженный на 10 равен нулю.
Почему стоимость кода равна нулю? Представьте, что у вас есть 2 разные библиотеки, которые решают одну и ту же задачу. Обе библиотеки работают одинаково корректно, но, одна библиотека заброшена несколько лет назад, а вокруг второй сформировалось сообщество разработчиков, которое активно развивает и поддерживает библиотеку. Какую библиотеку вы выберете? Конечно вторую. Более того, даже если бы второй библиотеки не существовало, вы бы всё равно в боевой проект не подключили бы первую. А почему? Да потому что вам важен не просто код, который решает задачу, а гарантированно верное решение, которое со временем не утратит свою актуальность, несмотря на выход новых версий языков и сопутствующих библиотек. Более того, вам важна уверенность в том, что если в решении найдётся ошибка, то она будет исправлена. Т.е. получается, что второе решение обладает для вас ценностью не потому, что оно работает, а потому, что его поддерживает сообщество инженеров. Т.е. ценностью обладает не код, а техническая экспертиза инженеров, которые его развивают и поддерживают.
Хорошо, а может ли результат работы LLM представлять для меня такую же ценность, как техническая экспертиза сообщества? Предположим, я подробно описал решение в виде спецификации и сгенерировал по ней код. Вышли новые версии языков/библиотек - перегенерировал. Нашлась ошибка - снова перегенерировал. Что здесь не так? А то, что LLM не обеспечивает строго детерменированную кодогенерацию, и не несёт ответственности (даже репутационной) за результат своей работы. Результат кодогенерации может содержать некоторое множество ошибок. Результат повторной кодогенерации по той же спеке и с тем же набором версий языков/библиотек может содержать другое множество ошибок, не равное первому. Как обеспечить гарантию качества кодогенерации? Да только если вы самостоятельно проведёте качественное ревью кода и обеспечите полноценное тестирование результата. Т.е. если вы проинвестируете в результат кодогенерации LLM своё рабочее время и свою техническую экспертизу.
Так чем же отличается результат кодогенерации LLM от первой, неподдерживаемой библиотеки? Да ничем! И там и там вы вынуждены будете инвестировать своё время и свою техническую экспертизу в долгосрочную поддержку полученного решения. Соответственно результат кодогенерации LLM для вас ничем не выгоднее, чем неподдерживаемая библиотека.
Т.е. чем ценна скачанная Open Source библиотека? Кодом? Нет, не кодом! А ценна она поддержкой сообщества, которое инвестирует своё время и техническую экспертизу в поддержку этого решения. И которому вы делегируете свою ответственность за долгосрочную стабильность и корректность этого решения.
Ну, на этом проекте джун не взлетит. А на проекте попроще - почему нет? Только джун нужен мотивированный и с хорошим техническим образованием, а не выпускник курсов. Чтобы системное мышление и навык обучения новому были развиты.
А запустили этот проект 2 человека. Один наполовину архитектор, наполовину разработчик. Другой наполовину девопс, наполовину разработчик. Ну и ИИ'шка, которой в основном тесты генерировали. Так как с жёстким хайлоадом и многопоточностью она не справляется. Куда уж меньше то?
Я сейчас такой лид :) И, с учётом масштаба проекта, моего "контекстного окна" катастрофически не хватает, чтобы уследить за всем. Поэтому единственный выход для меня - делегировать. А кому делегировать? Можно конечно сеньёру. Но попробуй его ещё найди, даже сейчас. И попробуй ещё с ним договориться - порой непросто бывает.
Так что для меня зачастую проще бывает взять мидла, и вырастить из него сеньёра "под себя".
Да, согласен. За свою карьеру я видел массу мёртворождённых проектов. Когда с самого начала очевидно, что проект ни о чём, и никакой пользы не принесёт. В ковидные годы их особенно много появилось. А сейчас, когда кредиты подорожали, бизнес конечно прикрывает такие проекты, и сокращает команды. Типичный кризис перепроизводства. Остаётся только надеяться, что в среднесрочной перспективе этот кризис оздоровит отрасль.
Видел конечно :) Написать сложно может любой дурак. А вот создать простое, понятное и легко читаемое решение сложной проблемы - это настоящее искусство.
ИИ кратно умножает и сильные и слабые стороны инженера. А вот представьте теперь себе такой "звёздный" код, умноженный с помощью ИИ :)
меряться пиписками - скучно. Я в разработке с 1980го, и - что?
Т.е. из всего моего поста вы увидели только упоминание об опыте работы и восприняли это как призыв "померяться пиписьками"? Очень грустно. И очень странно. Никогда бы не подумал, что мои высказывания можно так неадекватно интерпретировать.
Да, мы явно друг друга не понимаем. И это сулит и отрасли и бизнесу очень большие проблемы. Ну и как следствие, для меня это тоже может стать проблемой. И для вас тоже - несмотря на всю вашу самоуверенность.
В том то и дело, что видел их и до ИИ. И, боюсь себе даже представить, что будет, когда безответственные люди отпустят поводья, и начнут всё генерировать с помощью ИИ, проводя ревью по диагонали. И теряя постепенно техническую квалификацию и снижая тем самым качество ревью.
PS
И, на всякий случай. Не надо на меня вешать лейбл противника ИИ. Для меня это просто ещё один инструмент в моём арсенале. Как можно быть противником тяпки или лопаты? Просто не надо лопатой полоть сорняки а тяпкой вскапывать огород. Вот и всё.
Ну а я видел реальные инциденты и сбои на проде. Случаи потерь данных. Уязвимости с точки зрения безопасности. Проблемы с производительностью - и с пропускной способностью и со временем отклика. Видел архитектурные проблемы, из за которых невозможно было обеспечить горизонтальную масштабируемость. Видел гонки в многопоточных решениях и утечки памяти и ресурсов.
И всё это я видел на решениях, где архитектура и качество кода по моим оценкам были на топ уровне.
У нас просто немного разный опыт. Вам дали таблетки от головной боли, таблетки от проблем с пищеварением и жаропонижающее. И вы говорите - ну а зачем мне теперь врачи? А я, как "практикующий хирург", видел такие кейсы, которые вы себе даже представить не можете.
На лицо классический эффект Даннинга — Крюгера. Когда безграмотность порождает самоуверенность.
А дальше 2036 год, когда уголь = цене подписки, а Паровую машину человек создаёт сам, наговаривая промпт ассистенту ИИ на телефоне.
Ну или когда бизнес из за стремительной недетерменированной кодогенерации накопил такой техдолг, при котором денежные потери от инцидентов начали в сотни раз превышать экономию от ускорения разработки... ;)
Купил книгу. С удовольствием читаю! 👍
Идемпотентность: искусство не менять мир дважды
Хороший ответ. Вызывает уважение. Спасибо!
Что значит добавить идемпотентность в API создания заказа? Это значит, что в сам API необходимо добавить возможность передачи ключа идемпотентности, внедрить бизнес логику идемпотентного потребителя в сервис, реализующий API - доработать схему БД и/или кеши для хранения ключа идемпотентности, обеспечить корректную миграцию схемы БД и данных на проде, доработать оркестрацию/хореографию микросервисов вашей платформы для обеспечения передачи ключа идемпотентности по всей цепочке вызовов, решить проблему распределенного состояния гонки при сохранении ключа, проблему частичных отказов в распределённых транзакциях, внедрить механизм проверки ключа, обеспечить детерминированность ответов, обеспечить защиту бизнес логики идемпотентности от атак злоумышленников (например когда вам с одним и тем же ключём передают разные суммы). Со стороны потребителя идемпотентного API обеспечить корректную генерацию ключей идемпотентности и внедрить механизм retry'ев, проработать стратегию балансировки повторных запросов к идемпотентному API (Failover Routing, Retry Control, Exponential Backoff, Circuit Breaker, Retry Budgets).
По сути это гигантская архитектурная задача, затрагивающая все аспекты жизнедеятельности и все архитектурные слои вашей платформы. И вы эту задачу делегируете ИИ простым промптом из 5 слов?
Так какими же качествами должен обладать разработчик версии 2.0? Прежде всего развитой инженерной культурой, знанием и пониманием современных архитектурных паттернов, пониманием всех аспектов работы разрабатываемой платформы (а не только своего участка), доскональным пониманием бизнес логики, пониманием процессов внедрения изменений и решения инцидентов, развитой инженерной ответственностью.
А все тактические приёмы, которые вы описали в своей статье находятся даже не на втором, а на 10м месте. Единственный плюс этих приёмов состоит в том, что при отсутствии инженерной культуры вы раньше зафейлитесь, и бизнес потеряет меньше денег.
Да, так тоже, к сожалению бывает. Значит у вас просто не было другого выхода.
Да, бывает такая специфика. Я в IoT с этим сталкивался. Там протоколы и библиотеки взаимодействия с железяками гвоздями прибиты к производителям этих железяк.
Но, такая ситуация в отдельно взятых отраслях это скорее исключение из правила, чем правило. Просто эти отрасли не сумели перестроиться на более эффективный формат доставки ценности.
А теперь представьте, что в этой либе есть ещё один баг, который ваш LLM не заметил.
Если бы вы завели issue автору на починку бага, то он бы починил его и для вас, и для всех остальных пользователей либы. И тогда, вполне вероятно, кто нибудь заметил бы баг, который не заметили вы. И так же завёл бы issue. Соответственно починка второго бага стала бы для вас бесплатной.
А переписав либу вы взвалили на себя стоимость долгосрочной поддержки этой либы. Что вас не ускоряет, а замедляет.
Здесь вы описали сценарий ночного кошмара пользователей vendor lock-in решений. Такая библиотека становится не вашим активом, а вашим пассивом. Техническим долгом. Расплатиться по которому рано или поздно придётся. И плата по этому долгу может в разы превышать стоимость разработки вашего проекта.
Именно этот сценарий стал причиной появления открытых open source решений.
Попробуйте взглянуть на это с другой, немного парадоксальной стороны. Стоимость кода просто физически не может упасть, потому что код сам по себе ровным счётом ничего не стоит. Его стоимость и до появления ИИ равнялась нулю, и после появления ИИ так же равняется нулю - так как ноль, умноженный на 10 равен нулю.
Почему стоимость кода равна нулю? Представьте, что у вас есть 2 разные библиотеки, которые решают одну и ту же задачу. Обе библиотеки работают одинаково корректно, но, одна библиотека заброшена несколько лет назад, а вокруг второй сформировалось сообщество разработчиков, которое активно развивает и поддерживает библиотеку. Какую библиотеку вы выберете? Конечно вторую. Более того, даже если бы второй библиотеки не существовало, вы бы всё равно в боевой проект не подключили бы первую. А почему? Да потому что вам важен не просто код, который решает задачу, а гарантированно верное решение, которое со временем не утратит свою актуальность, несмотря на выход новых версий языков и сопутствующих библиотек. Более того, вам важна уверенность в том, что если в решении найдётся ошибка, то она будет исправлена. Т.е. получается, что второе решение обладает для вас ценностью не потому, что оно работает, а потому, что его поддерживает сообщество инженеров. Т.е. ценностью обладает не код, а техническая экспертиза инженеров, которые его развивают и поддерживают.
Хорошо, а может ли результат работы LLM представлять для меня такую же ценность, как техническая экспертиза сообщества? Предположим, я подробно описал решение в виде спецификации и сгенерировал по ней код. Вышли новые версии языков/библиотек - перегенерировал. Нашлась ошибка - снова перегенерировал. Что здесь не так? А то, что LLM не обеспечивает строго детерменированную кодогенерацию, и не несёт ответственности (даже репутационной) за результат своей работы. Результат кодогенерации может содержать некоторое множество ошибок. Результат повторной кодогенерации по той же спеке и с тем же набором версий языков/библиотек может содержать другое множество ошибок, не равное первому. Как обеспечить гарантию качества кодогенерации? Да только если вы самостоятельно проведёте качественное ревью кода и обеспечите полноценное тестирование результата. Т.е. если вы проинвестируете в результат кодогенерации LLM своё рабочее время и свою техническую экспертизу.
Так чем же отличается результат кодогенерации LLM от первой, неподдерживаемой библиотеки? Да ничем! И там и там вы вынуждены будете инвестировать своё время и свою техническую экспертизу в долгосрочную поддержку полученного решения. Соответственно результат кодогенерации LLM для вас ничем не выгоднее, чем неподдерживаемая библиотека.
Т.е. чем ценна скачанная Open Source библиотека? Кодом? Нет, не кодом! А ценна она поддержкой сообщества, которое инвестирует своё время и техническую экспертизу в поддержку этого решения. И которому вы делегируете свою ответственность за долгосрочную стабильность и корректность этого решения.
Ну, на этом проекте джун не взлетит. А на проекте попроще - почему нет? Только джун нужен мотивированный и с хорошим техническим образованием, а не выпускник курсов. Чтобы системное мышление и навык обучения новому были развиты.
А запустили этот проект 2 человека. Один наполовину архитектор, наполовину разработчик. Другой наполовину девопс, наполовину разработчик. Ну и ИИ'шка, которой в основном тесты генерировали. Так как с жёстким хайлоадом и многопоточностью она не справляется. Куда уж меньше то?
Я сейчас такой лид :) И, с учётом масштаба проекта, моего "контекстного окна" катастрофически не хватает, чтобы уследить за всем. Поэтому единственный выход для меня - делегировать. А кому делегировать? Можно конечно сеньёру. Но попробуй его ещё найди, даже сейчас. И попробуй ещё с ним договориться - порой непросто бывает.
Так что для меня зачастую проще бывает взять мидла, и вырастить из него сеньёра "под себя".
То "пиписьки", то "передёрнули". Извините, я не могу общаться в таком стиле. Это уровень школьников младших классов. Я давно вышел из этого возраста.
Да, согласен. За свою карьеру я видел массу мёртворождённых проектов. Когда с самого начала очевидно, что проект ни о чём, и никакой пользы не принесёт. В ковидные годы их особенно много появилось. А сейчас, когда кредиты подорожали, бизнес конечно прикрывает такие проекты, и сокращает команды. Типичный кризис перепроизводства. Остаётся только надеяться, что в среднесрочной перспективе этот кризис оздоровит отрасль.
Видел конечно :) Написать сложно может любой дурак. А вот создать простое, понятное и легко читаемое решение сложной проблемы - это настоящее искусство.
ИИ кратно умножает и сильные и слабые стороны инженера. А вот представьте теперь себе такой "звёздный" код, умноженный с помощью ИИ :)
Т.е. из всего моего поста вы увидели только упоминание об опыте работы и восприняли это как призыв "померяться пиписьками"? Очень грустно. И очень странно. Никогда бы не подумал, что мои высказывания можно так неадекватно интерпретировать.
Да, мы явно друг друга не понимаем. И это сулит и отрасли и бизнесу очень большие проблемы. Ну и как следствие, для меня это тоже может стать проблемой. И для вас тоже - несмотря на всю вашу самоуверенность.
В том то и дело, что видел их и до ИИ. И, боюсь себе даже представить, что будет, когда безответственные люди отпустят поводья, и начнут всё генерировать с помощью ИИ, проводя ревью по диагонали. И теряя постепенно техническую квалификацию и снижая тем самым качество ревью.
PS
И, на всякий случай. Не надо на меня вешать лейбл противника ИИ. Для меня это просто ещё один инструмент в моём арсенале. Как можно быть противником тяпки или лопаты? Просто не надо лопатой полоть сорняки а тяпкой вскапывать огород. Вот и всё.
Ну а я видел реальные инциденты и сбои на проде. Случаи потерь данных. Уязвимости с точки зрения безопасности. Проблемы с производительностью - и с пропускной способностью и со временем отклика. Видел архитектурные проблемы, из за которых невозможно было обеспечить горизонтальную масштабируемость. Видел гонки в многопоточных решениях и утечки памяти и ресурсов.
И всё это я видел на решениях, где архитектура и качество кода по моим оценкам были на топ уровне.
У нас просто немного разный опыт. Вам дали таблетки от головной боли, таблетки от проблем с пищеварением и жаропонижающее. И вы говорите - ну а зачем мне теперь врачи? А я, как "практикующий хирург", видел такие кейсы, которые вы себе даже представить не можете.
На лицо классический эффект Даннинга — Крюгера. Когда безграмотность порождает самоуверенность.
Ну или когда бизнес из за стремительной недетерменированной кодогенерации накопил такой техдолг, при котором денежные потери от инцидентов начали в сотни раз превышать экономию от ускорения разработки... ;)