Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
Добавь идемпотентность в API создания заказа.
Что значит добавить идемпотентность в API создания заказа? Это значит, что в сам API необходимо добавить возможность передачи ключа идемпотентности, внедрить бизнес логику идемпотентного потребителя в сервис, реализующий API - доработать схему БД и/или кеши для хранения ключа идемпотентности, обеспечить корректную миграцию схемы БД и данных на проде, доработать оркестрацию/хореографию микросервисов вашей платформы для обеспечения передачи ключа идемпотентности по всей цепочке вызовов, решить проблему распределенного состояния гонки при сохранении ключа, проблему частичных отказов в распределённых транзакциях, внедрить механизм проверки ключа, обеспечить детерминированность ответов, обеспечить защиту бизнес логики идемпотентности от атак злоумышленников (например когда вам с одним и тем же ключём передают разные суммы). Со стороны потребителя идемпотентного API обеспечить корректную генерацию ключей идемпотентности и внедрить механизм retry'ев, проработать стратегию балансировки повторных запросов к идемпотентному API (Failover Routing, Retry Control, Exponential Backoff, Circuit Breaker, Retry Budgets).
По сути это гигантская архитектурная задача, затрагивающая все аспекты жизнедеятельности и все архитектурные слои вашей платформы. И вы эту задачу делегируете ИИ простым промптом из 5 слов?
Так какими же качествами должен обладать разработчик версии 2.0? Прежде всего развитой инженерной культурой, знанием и пониманием современных архитектурных паттернов, пониманием всех аспектов работы разрабатываемой платформы (а не только своего участка), доскональным пониманием бизнес логики, пониманием процессов внедрения изменений и решения инцидентов, развитой инженерной ответственностью.
А все тактические приёмы, которые вы описали в своей статье находятся даже не на втором, а на 10м месте. Единственный плюс этих приёмов состоит в том, что при отсутствии инженерной культуры вы раньше зафейлитесь, и бизнес потеряет меньше денег.
Вы, по сути, очень подробно подтвердили тезис статьи.
Конечно, идемпотентность - это не пять слов работы. За ней стоят контракты, БД, гонки, ретраи, частичные отказы, безопасность и бизнес-логика.
Но статья не про то, что AI должен всё это сам угадать. Она про то, что сильный разработчик один раз превращает эти знания в архитектуру, тесты, правила и инструменты - а потом не пересказывает их заново в каждом промпте.
И да: инженерная культура, системное мышление и ответственность - это и есть основа разработчика 2.0. А описанные в статье приёмы - не замена этой культуре, а способ сделать её частью процесса, а не личной суперсилой одного сеньора.
Так что спор у нас скорее не о сути, а о том, насколько подробно нужно было расписать очевидное.
Точно подмечено. Добавлю ещё один слой, который обычно всплывает уже на проде: сам ключ – это полдела, сложнее договориться, что считать "тем же запросом" – совпадение ключа, тела, временного окна – и что возвращать на повторе: сохранённый результат или ошибку. Это уже не техническая, а бизнес-задача, и её ни одно "просто добавь идемпотентность" за тебя не решит.
[типаванга]Разработчик 3.0. В виду того, что нейросеть сама по себе является программой, которая обрабатывает входящую информацию согласно обученной функции преобразования, то после прохода точки сингулярности весной 2030 г. (а вы хорошо помните, как директивно стали запрещать использовать любые классические программы кроме нейросетей после того ада атак обученных LLM и отказов всего самописного ПО по всему миру) само понятие разработчик компьютерных программ под строгим запретом. Разрешено только писать небольшие скрипты для 3% недетерменированности, которая еще не закрыта у современных нейросетей (мы горды тем, что наши модели с вероятностью 97% отвечают на любую поставленную задачу), но эта привилегия осталась у разработчиков больших моделей. Встречаются индивиды, которые на своих допотопных домашних компьютерах что то делают для себя и узкого круга таких же повстанцев, но последние законы заставят их отказаться от своих действий [/типаванга]
Хорошо, уберем шутки. А чего я неправильного написал в определении нейросети? Вроде ничего. Тогда вопрос: зачем программу заставлять писать другие программы, когда она - программа. Она что, входной поток не разберёт при правильной обвязке и настройках, или в нужном формате данные на выходе не выдаст, если ей надеть экзоскелет хотя бы на старом uml и пример обработки входного потока дать. А если этот экзоскелет - доменная модель какого-нибудь бизнес процесса? И что в сухом остатке будет для не моделей людей? Обвязки обвязывать?
Для того чтобы сложить 2+2 не надо запускать нейросеть на триллион параметров.
Считайте созданные нейросетью программы для складывания чисел её собственной обвязкой/кешем.
Всё таки созданные нейросетью программы - это выходные данные, которые суть - результат работы ее обученной функции преобразования входной информации. И да, продолжая шаблон автора, раньше с нас требовали много чего делать, а теперь 2.0 - программирует условия. А я попробовал развить его тему: 3.0 будет программировать намерения, обвязка будет выравнивать ответы в сторону детерминизма. С развитием таких механизмов и учитывая исторические аналогии вполне вероятен переход к очень специализированным локальным моделям и с меньшим числом параметров, вполне себе и на несколько миллиардов. И пусть себе шуршит сегодня под одну задачу, а завтра под другую.
По этой градации я где-то между 0.7 и 0.9 и планирую там и оставаться.
Во всех параллелях, проводимыми с предыдущими уровнями абстракции инструментов в программировании (машинные коды, ассемблер, языки программирования, фреймворки и т. п.) полностью упускается один момент: до сих пор все уровни абстракции оставались строго детерминированы.
Несмотря на возрастающую сложность действий на каждом следующем уровне, это все оставалось строго механическим преобразованием. Если в результате получается что-то отличное от заранее прогнозируемого результата со строгой спецификацией -- это критическая ошибка в инструменте.
ИИ вносит в процесс случайность, которая на предыдущих этапах в процессе абстрагирования считалась недопустимой.
Играет ли это отличие какую-то роль на практике -- пока сложно сказать, с точки зрения сильно внешнего наблюдателя (например, пользователя программы) наверное разницы никакой.
Но во-первых, это не еще один такой же этап абстракции в инструментах разработки, а качественно другой со своими особенностями.
А во-вторых, это не какой-то новый этап абстракции. Просто ранее недетерминированный процесс перевода в общих чертах описанных требований в код выполнялся более младшими разработчиками: сеньор говорил мидлу добавить идемпотентность, тот декомпозировал и отдавал задачки агентам-джунам (должности и грейды подставьте по вкусу).
Просто теперь всем условно говоря раздали кучу чрезвычайно исполнительных, но безинициативных джунов и мидлов и с этим надо что-то делать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработчик 2.0. Следующий уровень абстракции