Не нужно ничего обналичивать, например, я могу принимать за свои услуги как крипту, так и наличные доллары. Так что нужно лишь найти подходящего человека или организацию, которая без обналичивания предоставит вам товар или услугу, а есть еще прямой бартер. В гос. учреждениях, например, распространено работать по бартеру - обмен рекламой с коммерческими организациями и т.п.
Я бы в этом вопросе не сильно полагался на слова пользователей. Когда люди теряют деньги, они часто либо не помнят деталей, либо находятся в стрессе и тогда появляется формулировка "я точно не выбирал эту опцию". Это вполне человеческая реакция.
Плюс отсутствие обычных чекбоксов в коде интерфейса ничего не доказывает. Такие вещи легко могут быть реализованы как кнопки или блоки с картинкой.
По своему опыту, например, при заказах на WB я сам включал и отключал подобные опции - и ничего лишнего без моего ведома не подключалось. Если бы они массово активировались рандомно, скорее всего, жалоб было бы намного больше. Конечно, можно реализовать так, что на какой-то % от заказов включалась бы эта опция, но вряд ли это того бы стояло, достаточно пользователей сами это включат.
Но это не отменяет того, что сама схема с навязыванием кредитов является незаконной. Я, например, однажды сталкивался с рассрочкой от Т-банка - при оформлении туда была "зашита" платная подписка какой-то сторонней организации, причем скрытая под сноской. Формально это есть в договоре, но по факту выглядит как способ дополнительно заработать.
Отключить такую подписку можно, но это уже отдельный квест: нужно найти контакты, написать обращение, потратить время. При этом сам банк как будто "ни при чём", хотя услуга появляется именно в процессе оформления у них.
Так у нас фаза тестирования остается, unit-тесты, автотесты, и быть может интеграционные тесты, или ручные тесты должны проверять на выходе, что полученные результат после изменений не изменился, иначе модель отправляется переделывать решение до тих пор, пока не стабилизируется.
Если же у вас есть компетентные люди и выработанные процессы, там и так вероятность ошибок сведена к минимуму — там не просто так тонна бюрократии на каждый чих.
Это все классно, например, до тех пор, пока организация не сталкивается с финансовыми проблемами. И предположим, ради спасения компании ЛПР решает сократить компетентных людей и воспользоваться ИИ вместо них всех, или частично. В таком случае множество работы падает на оставшихся, тогда они могут не вывести весь объемы работ, но с помощью ИИ они могут выполнять необходимый за то же время.
Одинаковый промт должен лишь давать одинаковый результат, но не обязательно одинаковый код/продукт. Если при первой генерации, чтобы распечатать LaTeX-формулы на странице A4 строго определенного формата, мы получили, условно, Word, то при следующей генерации мы, условно, выйдет LibreOffice, но при этом задача будет выполняться корректно согласно требованиям, то нам не важно, как внутри это реализовано и что используется (то же самое, что каждый разработчик любит переписывать код на своем языке, использовать свою любимую библиотеку или писать велосипед), а если важно - достаточно описать это в промте.
следующая версия модели будет генерировать настолько же корректный/оптимальный код
В этом нет необходимости, если у нас прописано по спецификации, что A x2 = 2A, и что вычисление должны выполняться за X ms и будут тесты, которые это проверят. Тогда нам не важно, что внутри, хоть C библиотеку подключит, хоть python (если нам и это не важно), но, если результат будет удовлетворять требованиям, то этого будет достаточно. Это по сути, как отметили выше - другая парадигма разработки, другой уровень абстракции.
Да, для safety-critical систем это вообще отдельная тема, там другие правила. В таких проектах основная стоимость - это не разработка, а верификация и сертификация. Поэтому любые изменения, независимо от того, кто их сделал (человек или ИИ), автоматически дорогие.
В этом смысле ИИ скорей больше вредит, чем упрощает: перегенерация кода не снижает стоимость, потому что ее все равно нужно заново проверять и доказывать корректность - в этом плане быстрее написать самому с нуля, чем разбираться в ИИ коде.
Но здесь ИИ может быть полезен в остальном: помогать готовить спецификации и требования, проверять соответствие кода и документации например, на случай, если человек что-то пропустил, а так же придумывать различные идеи, более дешевые в реализации. То есть не заменять процесс, а снижать вероятность ошибок до того, как они попадут в дорогую стадию сертификации и возможно, минимизировать затраты на разработку.
Выгода не в том, что английский текст "лучше" языка программирования. Понятно, что для разработчика код компактнее, однозначнее и удобнее. Выгода в другом, в том, что это язык, который понимают не только разработчики.
Когда спецификация описана на уровне моделей, сценариев и правил на человеческом языке, с ней могут работать аналитики, продукт, бизнес. Они могут вносить правки, проверять, валидировать. То есть уменьшается разрыв между "что хотим" и "что реализовано".
С точки зрения бизнеса это выглядит как плюс: меньше зависимость от конкретных разработчиков, больше людей могут влиять на систему, быстрее итерации на уровне требований. Понятно, что этот обмен для разработчика часто менее эффективен, чем писать код напрямую.
Но бизнес оптимизирует даже не сколько локальную эффективность разработчика, а хочет в целом меньше тратить денег на разработку и поддержку. И он, по крайней мере, хочет верить, что такой подход это дает - иначе бы не было всех этих историй с заменой части разработки на ИИ (где это реально причина, а не просто удобное объяснение сокращений).
Буквально так и есть - ответственность никуда не девается, она всегда на владельце продукта, организации, частично на команде, и ее на ИИ не переложишь.
Но из этого не следует, что ИИ бесполезен в проде. Наоборот, в ситуации, когда "каждый час капают деньги", важно максимально быстро найти и исправить проблему. И здесь ИИ уже помогает: быстрее разобрает логи, предлогает гипотезы, указывает на потенциальную причину и даже способен чуть ли не моментально подготовить фикс.
Так что писать молитвы в чат вполне оправдано, это мощный инструмент, который ускоряет диагностику и восстановление.
Решение, выкатывать ли фикс, как действовать с данными, как пройти через инцидент - все равно принимает человек. Но если ИИ позволяет сократить время поиска причины с часов до минут, это напрямую экономит деньги.
С хардварными проблемами, понятно, он не заменит инженера. Но и там он может помочь быстрее сузить круг поиска и предложить возможные варианты решения.
Если честно, я еще примерно в 2017 топил за похожую идею. Тогда казалось, что основной код ИС можно генерировать из формализованных моделей, например, BPMN-диаграмм, которые делают системные аналитики. То есть бизнес-процессы описываются на уровне схем, а система из этого собирается автоматически. А разработчики в основном пишут только те низкоуровневые модули/микросервисы, которых не хватает или которые требуют ручной оптимизации.
По сути, это попытка поднять уровень абстракции: не писать код руками, а описывать систему и генерировать ее.
Сейчас, с ИИ, к этому можно подойти ближе: уже можно пробовать генерировать сами микросервисы на основе спецификаций, контрактов и документации. Но это не значит, что "достаточно уметь писать ТЗ". Скорее, ценность смещается в сторону умения формализовать требования, описывать процессы, ограничения, контракты так, чтобы их можно было однозначно интерпретировать.
При этом интересный момент: с появлением агентных систем (типа того же Clawdbot и подобных) часть работы системного аналитика тоже потенциально может автоматизироваться - сбор требований, декомпозиция, генерация спецификаций.
Так что, скорее, не "одна профессия станет главной", а общий сдвиг идет в сторону людей, которые умеют переводить бизнес-задачу в формальную, проверяемую модель системы.
Хорошо, можно подойти с другой стороны к этой проблеме с огромными энтерпрайз системами. По своему опыту могу сказать, что исторически у нас, да наверно и у большинства, было так: был монолит, его понимали только разработчики. Потом его разбили на микросервисы, и появилась необходимость явно описывать контракты, схемы, логику - OpenAPI, AS-IS, подробно составлять бизнес-правила. То есть часть "знаний" уже вынесли из кода в документацию.
Осталось сделать следующий шаг: если у нас есть формализованная спецификация (контракты, модели данных, правила, тесты), то ошибка - это часто не только баг в коде, а проблема в самой спецификации.
Тогда вместо того, чтобы бесконечно править код, можно: исправить спецификацию или найти расхождения между документацией и кодом, и перегенерировать или обновить конкретный модуль. Не всю систему, а локально и под контролем unit-тестов, авто-тестов. И тогда проблема cross-repo тут как раз минимизируется: модель не "угадывает" систему, а опирается на явные контракты и требования.
То есть, в таком случае, не нужно все снести и заново сгенерить, а сделать, чтобы код стал воспроизводимым артефактом от спецификации, а не единственным источником истины. Да в этом случае, мы скорей всего не избавимся от программистов, потому что, нужно проверять миграции в случае изменения модели данных, но это явно их минимизует или очень сильно ускорит. Например, если изменилось какое-то требование в документации, не связанное с изменением данных, SA может выпустить эту доработку без программистов, просто, запустив pipeline, который посмотрит что изменилось, найдет и исправит нужный модуль с помощью ИИ и получит готовое решение с этим изменением.
Я бы на это посмотрел немного с другой стороны. Кажется, что здесь проблема в том, что к ИИ пытаются применять классическую модель разработки. Мы привыкли, что если в коде есть ошибка, это значит, что нужно найти ее и исправить код. Но с llm это не всегда так работает.
Когда ты берёшь сгенерированный код и начинаешь просить модель внести точечные правки или правишь руками, как раз и возникают проблемы из-за потери контекста, модель правя в одном месте ломает, что-то другое и так много раз.
Но если смотреть на это как на AI-first подход, то логика здесь немного другая. Если в коде есть ошибка, то это часто не только проблема кода, а проблема в постановке задачи, то есть в промте. Вместо того чтобы чинить следствие, логичнее поправить причину: уточнить требования, явно задать ограничения, описать negative, edge cases, зафиксировать архитектуру, контракты, форматы данных. И после этого просто перегенерировать программу с нуля.
Это звучит непривычно, потому что противоречит классическому SDLC, но на практике часто оказывается, что перегенерировать быстрее, чем разбираться в сгенерированном (считай в чужом) коде, и код получается более целостным и консистентным, и не накапливается технический долг из-за бесконечных правок.
По опыту я и сам могу сказать, что когда собирал mvp некоторого стартапа, то с первого раза мне llm сгенерировала вполне подходящее решение и все работало, но я не учел маленькую деталь, и мне потребовалось несколько часов итераций чтобы внести эту правку и затем восстановить работоспособность остальных частей. Если бы я знал, что потрачу столько времени на доработки, то я бы лучше несколько раз с нуля доработал промт и перегенерировал код с нуля и сэкономил бы кучу времени. Однако, это было еще где-то чуть больше года назад, с тех пор модели куда больше продвинулись и появились агенты.
По сути, промт начинает играть роль единственного источника правды, а код становится артефактом, который можно в любой момент пересобрать. И тогда меняется сама задача разработчика: ты уже не столько дебажишь код, сколько дебажишь спецификацию, то есть сам промт или тз как хотите.
Понятно, что это пока не серебряная пуля, но многие проблемы, о которых вы говорите, как раз возникают из попытки использовать ИИ как обычного разработчика, а не как инструмент более высокого уровня, условный "компилятор" для создания нужной вам системы.
Среди моих знакомых был случай, когда было автоматическое списание проезда, потому что кто-то с похожей внешностью расплатился биометрией, так что сама биометрия, а точнее сам "слепок", по которому она строится не такой уж и уникальный.
Если система очень большая, то "проверить восстановление из резервных копий" невозможно потому что или нет достаточно ресурсов (попробуй восстанови бэкап на 2-10 ТБ) или времени, пока база в процессе восстановления - нужно успевать писать уже новый бэкап, а старый становится неактуальным. А если базы меньше, но их очень много, то проблема может быть в их согласованности, так как бэкапы не одновременно создаются.
Было бы гораздо понятнее и интереснее, если бы вы код и описание иллюстрировали скринами вашего приложения.
ГК РФ - это хорошо, но у меня дома свой локальный кодекс 😄, но он распространяется только на проверенных людей, которым я доверяю.
Интересно, как контролировать то, чего нет?
Не нужно ничего обналичивать, например, я могу принимать за свои услуги как крипту, так и наличные доллары. Так что нужно лишь найти подходящего человека или организацию, которая без обналичивания предоставит вам товар или услугу, а есть еще прямой бартер. В гос. учреждениях, например, распространено работать по бартеру - обмен рекламой с коммерческими организациями и т.п.
Я бы в этом вопросе не сильно полагался на слова пользователей. Когда люди теряют деньги, они часто либо не помнят деталей, либо находятся в стрессе и тогда появляется формулировка "я точно не выбирал эту опцию". Это вполне человеческая реакция.
Плюс отсутствие обычных чекбоксов в коде интерфейса ничего не доказывает. Такие вещи легко могут быть реализованы как кнопки или блоки с картинкой.
По своему опыту, например, при заказах на WB я сам включал и отключал подобные опции - и ничего лишнего без моего ведома не подключалось. Если бы они массово активировались рандомно, скорее всего, жалоб было бы намного больше. Конечно, можно реализовать так, что на какой-то % от заказов включалась бы эта опция, но вряд ли это того бы стояло, достаточно пользователей сами это включат.
Но это не отменяет того, что сама схема с навязыванием кредитов является незаконной. Я, например, однажды сталкивался с рассрочкой от Т-банка - при оформлении туда была "зашита" платная подписка какой-то сторонней организации, причем скрытая под сноской. Формально это есть в договоре, но по факту выглядит как способ дополнительно заработать.
Отключить такую подписку можно, но это уже отдельный квест: нужно найти контакты, написать обращение, потратить время. При этом сам банк как будто "ни при чём", хотя услуга появляется именно в процессе оформления у них.
Так по итогу выходит ничто никого не заменит и это бесперспективно?
Так у нас фаза тестирования остается, unit-тесты, автотесты, и быть может интеграционные тесты, или ручные тесты должны проверять на выходе, что полученные результат после изменений не изменился, иначе модель отправляется переделывать решение до тих пор, пока не стабилизируется.
Конечно, unit-тесты, автотесты и интеграционные тесты проверят, чтобы результат совпадал.
Это все классно, например, до тех пор, пока организация не сталкивается с финансовыми проблемами. И предположим, ради спасения компании ЛПР решает сократить компетентных людей и воспользоваться ИИ вместо них всех, или частично. В таком случае множество работы падает на оставшихся, тогда они могут не вывести весь объемы работ, но с помощью ИИ они могут выполнять необходимый за то же время.
Одинаковый промт должен лишь давать одинаковый результат, но не обязательно одинаковый код/продукт. Если при первой генерации, чтобы распечатать LaTeX-формулы на странице A4 строго определенного формата, мы получили, условно, Word, то при следующей генерации мы, условно, выйдет LibreOffice, но при этом задача будет выполняться корректно согласно требованиям, то нам не важно, как внутри это реализовано и что используется (то же самое, что каждый разработчик любит переписывать код на своем языке, использовать свою любимую библиотеку или писать велосипед), а если важно - достаточно описать это в промте.
В этом нет необходимости, если у нас прописано по спецификации, что A x2 = 2A, и что вычисление должны выполняться за X ms и будут тесты, которые это проверят. Тогда нам не важно, что внутри, хоть C библиотеку подключит, хоть python (если нам и это не важно), но, если результат будет удовлетворять требованиям, то этого будет достаточно. Это по сути, как отметили выше - другая парадигма разработки, другой уровень абстракции.
Да, для safety-critical систем это вообще отдельная тема, там другие правила. В таких проектах основная стоимость - это не разработка, а верификация и сертификация. Поэтому любые изменения, независимо от того, кто их сделал (человек или ИИ), автоматически дорогие.
В этом смысле ИИ скорей больше вредит, чем упрощает: перегенерация кода не снижает стоимость, потому что ее все равно нужно заново проверять и доказывать корректность - в этом плане быстрее написать самому с нуля, чем разбираться в ИИ коде.
Но здесь ИИ может быть полезен в остальном: помогать готовить спецификации и требования, проверять соответствие кода и документации например, на случай, если человек что-то пропустил, а так же придумывать различные идеи, более дешевые в реализации. То есть не заменять процесс, а снижать вероятность ошибок до того, как они попадут в дорогую стадию сертификации и возможно, минимизировать затраты на разработку.
Выгода не в том, что английский текст "лучше" языка программирования. Понятно, что для разработчика код компактнее, однозначнее и удобнее. Выгода в другом, в том, что это язык, который понимают не только разработчики.
Когда спецификация описана на уровне моделей, сценариев и правил на человеческом языке, с ней могут работать аналитики, продукт, бизнес. Они могут вносить правки, проверять, валидировать. То есть уменьшается разрыв между "что хотим" и "что реализовано".
С точки зрения бизнеса это выглядит как плюс: меньше зависимость от конкретных разработчиков, больше людей могут влиять на систему, быстрее итерации на уровне требований. Понятно, что этот обмен для разработчика часто менее эффективен, чем писать код напрямую.
Но бизнес оптимизирует даже не сколько локальную эффективность разработчика, а хочет в целом меньше тратить денег на разработку и поддержку. И он, по крайней мере, хочет верить, что такой подход это дает - иначе бы не было всех этих историй с заменой части разработки на ИИ (где это реально причина, а не просто удобное объяснение сокращений).
Буквально так и есть - ответственность никуда не девается, она всегда на владельце продукта, организации, частично на команде, и ее на ИИ не переложишь.
Но из этого не следует, что ИИ бесполезен в проде. Наоборот, в ситуации, когда "каждый час капают деньги", важно максимально быстро найти и исправить проблему. И здесь ИИ уже помогает: быстрее разобрает логи, предлогает гипотезы, указывает на потенциальную причину и даже способен чуть ли не моментально подготовить фикс.
Так что писать молитвы в чат вполне оправдано, это мощный инструмент, который ускоряет диагностику и восстановление.
Решение, выкатывать ли фикс, как действовать с данными, как пройти через инцидент - все равно принимает человек. Но если ИИ позволяет сократить время поиска причины с часов до минут, это напрямую экономит деньги.
С хардварными проблемами, понятно, он не заменит инженера. Но и там он может помочь быстрее сузить круг поиска и предложить возможные варианты решения.
Если честно, я еще примерно в 2017 топил за похожую идею. Тогда казалось, что основной код ИС можно генерировать из формализованных моделей, например, BPMN-диаграмм, которые делают системные аналитики. То есть бизнес-процессы описываются на уровне схем, а система из этого собирается автоматически. А разработчики в основном пишут только те низкоуровневые модули/микросервисы, которых не хватает или которые требуют ручной оптимизации.
По сути, это попытка поднять уровень абстракции: не писать код руками, а описывать систему и генерировать ее.
Сейчас, с ИИ, к этому можно подойти ближе: уже можно пробовать генерировать сами микросервисы на основе спецификаций, контрактов и документации. Но это не значит, что "достаточно уметь писать ТЗ". Скорее, ценность смещается в сторону умения формализовать требования, описывать процессы, ограничения, контракты так, чтобы их можно было однозначно интерпретировать.
При этом интересный момент: с появлением агентных систем (типа того же Clawdbot и подобных) часть работы системного аналитика тоже потенциально может автоматизироваться - сбор требований, декомпозиция, генерация спецификаций.
Так что, скорее, не "одна профессия станет главной", а общий сдвиг идет в сторону людей, которые умеют переводить бизнес-задачу в формальную, проверяемую модель системы.
Хорошо, можно подойти с другой стороны к этой проблеме с огромными энтерпрайз системами. По своему опыту могу сказать, что исторически у нас, да наверно и у большинства, было так: был монолит, его понимали только разработчики. Потом его разбили на микросервисы, и появилась необходимость явно описывать контракты, схемы, логику - OpenAPI, AS-IS, подробно составлять бизнес-правила. То есть часть "знаний" уже вынесли из кода в документацию.
Осталось сделать следующий шаг: если у нас есть формализованная спецификация (контракты, модели данных, правила, тесты), то ошибка - это часто не только баг в коде, а проблема в самой спецификации.
Тогда вместо того, чтобы бесконечно править код, можно: исправить спецификацию или найти расхождения между документацией и кодом, и перегенерировать или обновить конкретный модуль. Не всю систему, а локально и под контролем unit-тестов, авто-тестов. И тогда проблема cross-repo тут как раз минимизируется: модель не "угадывает" систему, а опирается на явные контракты и требования.
То есть, в таком случае, не нужно все снести и заново сгенерить, а сделать, чтобы код стал воспроизводимым артефактом от спецификации, а не единственным источником истины. Да в этом случае, мы скорей всего не избавимся от программистов, потому что, нужно проверять миграции в случае изменения модели данных, но это явно их минимизует или очень сильно ускорит. Например, если изменилось какое-то требование в документации, не связанное с изменением данных, SA может выпустить эту доработку без программистов, просто, запустив pipeline, который посмотрит что изменилось, найдет и исправит нужный модуль с помощью ИИ и получит готовое решение с этим изменением.
Я бы на это посмотрел немного с другой стороны. Кажется, что здесь проблема в том, что к ИИ пытаются применять классическую модель разработки. Мы привыкли, что если в коде есть ошибка, это значит, что нужно найти ее и исправить код. Но с llm это не всегда так работает.
Когда ты берёшь сгенерированный код и начинаешь просить модель внести точечные правки или правишь руками, как раз и возникают проблемы из-за потери контекста, модель правя в одном месте ломает, что-то другое и так много раз.
Но если смотреть на это как на AI-first подход, то логика здесь немного другая. Если в коде есть ошибка, то это часто не только проблема кода, а проблема в постановке задачи, то есть в промте. Вместо того чтобы чинить следствие, логичнее поправить причину:
уточнить требования, явно задать ограничения, описать negative, edge cases, зафиксировать архитектуру, контракты, форматы данных. И после этого просто перегенерировать программу с нуля.
Это звучит непривычно, потому что противоречит классическому SDLC, но на практике часто оказывается, что перегенерировать быстрее, чем разбираться в сгенерированном (считай в чужом) коде, и код получается более целостным и консистентным, и не накапливается технический долг из-за бесконечных правок.
По опыту я и сам могу сказать, что когда собирал mvp некоторого стартапа, то с первого раза мне llm сгенерировала вполне подходящее решение и все работало, но я не учел маленькую деталь, и мне потребовалось несколько часов итераций чтобы внести эту правку и затем восстановить работоспособность остальных частей. Если бы я знал, что потрачу столько времени на доработки, то я бы лучше несколько раз с нуля доработал промт и перегенерировал код с нуля и сэкономил бы кучу времени. Однако, это было еще где-то чуть больше года назад, с тех пор модели куда больше продвинулись и появились агенты.
По сути, промт начинает играть роль единственного источника правды, а код становится артефактом, который можно в любой момент пересобрать. И тогда меняется сама задача разработчика: ты уже не столько дебажишь код, сколько дебажишь спецификацию, то есть сам промт или тз как хотите.
Понятно, что это пока не серебряная пуля, но многие проблемы, о которых вы говорите, как раз возникают из попытки использовать ИИ как обычного разработчика, а не как инструмент более высокого уровня, условный "компилятор" для создания нужной вам системы.
Текст для этой статьи писал chat gpt, его структура прям один в один как пишет подобные тексты.
Среди моих знакомых был случай, когда было автоматическое списание проезда, потому что кто-то с похожей внешностью расплатился биометрией, так что сама биометрия, а точнее сам "слепок", по которому она строится не такой уж и уникальный.
Если система очень большая, то "проверить восстановление из резервных копий" невозможно потому что или нет достаточно ресурсов (попробуй восстанови бэкап на 2-10 ТБ) или времени, пока база в процессе восстановления - нужно успевать писать уже новый бэкап, а старый становится неактуальным. А если базы меньше, но их очень много, то проблема может быть в их согласованности, так как бэкапы не одновременно создаются.