От двух крайностей – к поиску баланса
Сейчас достаточно активно обсуждается тема, что разработчиков можно заменить агентами. Особенно часто в этом контексте звучит Anthropic Claude: можно все делать быстро, буквально за часы. Например, я видел кейс, когда кто-то сделал за два часа проект, который обычно с точки зрения разработки занимает порядка двух месяцев. Понятно, что во всем этом есть определенная доля модности и нагнетания.
Так получилось, достаточно случайным образом, что в рамках нашей работы с двумя сервисами – причем очень разными и по разным причинам – мы решили в той или иной степени использовать ИИ. Отчасти эта работа еще не завершена, но я решил немного обобщить опыт. Я в том числе занимаюсь методологией, мне самому это интересно.
Здесь всегда есть две крайности, которые методологически можно рассматривать как два полюса. Одна крайность – условно полностью ИИ-команда. Понятно, что это совершенно гипотетическая ситуация. Другая крайность – полностью команда из людей. Вопрос в том, где между этими двумя крайностями найти нужную позицию. Мне нравится аналогия с регулятором: сдвинуть ползунок немного в одну сторону или немного в другую.
Выбор положения этого регулятора основан на ключевых параметрах: экономической эффективности, скорости выхода на рынок, информационной безопасности. Это достаточно понятные вещи, и именно их я попробую оценить.
Сразу очерчу ограничения. Я ни в коем случае не претендую на всеобъемлющность – ее пока просто нет. Как я уже сказал, эта работа еще идет, и результаты наверняка будут меняться. Буквально недавно мы обсуждали некоторые вещи с коллегами, и часть оценок уже начинает уточняться.
Одно из основных ограничений состоит в том, что сравнение, которое я хочу представить, относится к сегменту малого и среднего бизнеса и к решениям, выводимым на открытый публичный рынок.
При этом, работая с крупными компаниями, я прекрасно понимаю, что там существуют свои корпоративные ограничения, сложности и политики. Поэтому для корпоративного сегмента, тем более для государственного, некоторые вещи здесь просто будут нерелевантны или неприменимы. Это ограничение нужно учитывать изначально.
Два проекта для сравнения
Для начала представлю два сервиса, на основании которых я делаю сравнение.
Первый сервис (слева) технологически и, что, может быть, еще важнее, логистически – с точки зрения бизнес-логистики – относительно простой. Это B2B-сегмент, сервис, предоставляющий услугу в области аудита, онлайн- и гибридного обучения.
Клиенты – B2B, здесь присутствуют элементы прямого взаимодействия. Поэтому для некоторого упрощения я использую термин «сайт». Конечно, это не буквально какой-то сайт, а веб-сервис. Он достаточно простой и с точки зрения выстраивания бизнес-процесса, и с точки зрения реализации. В контексте применения ИИ это как раз один из ключевых моментов.
Второй сервис (справа) пока еще даже не вышел в продуктив, но я использовал его для сравнения, поскольку там ситуация другая. Он гораздо сложнее с точки зрения клиентской, партнерской и технологической логистики. И результаты использования ИИ и агентов здесь достаточно серьезно отличаются. На этом и можно построить сравнение.
OESI сайт: Разработка версии 1 вручную
По первому сервису у меня есть возможность, обладая внутренней информацией, провести достаточно чистое сравнение.
Версия 1 была классически разработана командой людей. Состав команды был вполне типовым. Сервис достаточно давно выпустили на рынок, он существовал и работал. Как всегда бывает с любым сервисом, со временем возникла необходимость провести обновление.
Поскольку необходимость в обновлении появилась примерно год назад, возникла мысль: а почему бы не попробовать использовать ИИ-агента?
Эта мысль возникла не на пустом месте и не просто из энтузиазма. При разработке первой версии были вполне типичные сложности работы с командой. Ничего особенного – все довольно стандартно. Выпуск несколько затянулся, потому что возникали определенные разногласия между нашей частью команды – мы в этом случае выполняли роль генераторов идей и инвесторов – и ключевым архитектором. Все это несколько увеличило сроки и сложность разработки. Поэтому решили попробовать другой подход.
Результат превзошел наши ожидания. Те четыре часа трудозатрат со стороны инвестора, которые указаны в расчетах, – это действительно четыре часа. Речь идет обо мне как о человеке с IT-бэкграундом.
Мне было интересно самому разобраться, и в какой-то момент я понял, что дольше буду ставить задачу системному аналитику, потом все это будет согласовываться и проходить по цепочке. Здесь же все было сделано практически на лету.
Разумеется, это не означает, что весь проект занял четыре часа. Четыре часа – это именно трудозатраты на чисто техническое создание на определенной платформе новой версии сервиса. Еще раз подчеркну: сам сервис весьма прост и с точки зрения бизнес-логистики – это поставка определенного аудита по запросу, – и с точки зрения реализации.
ReferenceChain: Персональное онлайн портфолио/CV
Второй сервис стоит рассмотреть подробнее, потому что его особенности оказали и продолжают оказывать влияние на результаты. Эта история еще не завершена.
Это сервис в области дополнительного образования и развития карьеры, связанный с созданием цифрового верифицированного портфолио для студентов и молодых специалистов.
Здесь достаточно сложная бизнес-логистика. Одна группа пользователей – молодые специалисты и студенты, которым необходимо как-то выделить свое портфолио или резюме, привлечь к нему внимание, верифицировать его, накапливать информацию и быстро организовывать ее для различных работодателей.
Но с точки зрения бизнеса сами эти пользователи клиентами не являются. Клиентами могут быть, например, организаторы конференций. Условно, выступление можно представить как NFT-объект. То же самое может относиться к защите диплома и другим событиям.
Другой вид клиентов – учебные заведения. Интерес к такой схеме проявили рекрутинговые агентства и, как ни странно, в топе оказались банки и страховые компании: решение может помогать им в скоринге.
Получается сложная логистика: совершенно разнородные бизнесы, разные идеи монетизации и достаточно сложная технологическая составляющая. Решение основано на блокчейне, присутствует NFT-минтинг для разных видов документов, а вместе с этим сразу возникают вопросы, где и как все это хранить, как верифицировать изменения и так далее.
То есть составляющая совершенно другая. Изначально никакой мысли о том, чтобы использовать здесь ИИ, не было. Идея появилась из проблем.
Наверное, это достаточно типичная ситуация: переход к чему-то новому часто вызывается жесткой необходимостью, возникшими сложностями или проблемами. Когда мы выпускали рабочий прототип совершенно классической командой, возникло сразу несколько сложностей.
Во-первых, это узкая технологическая область. Во-вторых, сложность поиска специалистов и их дороговизна. В-третьих, необходимость управлять сотрудниками, обладающими уникальными компетенциями и вследствие этого достаточно слабо управляемыми.
В результате мы столкнулись с упущенными возможностями при работе с ключевыми партнерами. Для обкатки бизнес-идей, естественно, нужно было взаимодействовать с ними на ранних стадиях, а мы срывали сроки. Все выглядело не очень хорошо.
Когда возникла необходимость переходить от рабочего прототипа к первой продуктивной версии – это уже прошлый и начало этого года, – появилась идея попробовать заменить именно разработчиков на ИИ.
Переход к ИИ, естественно, тоже потребовал поиска и изучения платформ, а также обучения команды. Но уже какой команды? В первую очередь команды аналитиков.
Главным результатом стала очень быстрая адаптация требований. Именно это для нас было наиболее важным и критичным. Речь идет о пресловутом time to market – быстроте вывода на рынок – и гибкости внесения изменений.
Я не случайно подробнее остановился на сложности бизнес-логистики второго сервиса. У нас есть самые разные виды потенциальных клиентов, именно тех, которые генерируют денежный поток. И у каждой группы свои пожелания.
Например, если банки выходят в топ и проявляют наибольший интерес к использованию решения для своих скоринговых задач, нам необходимо быстро адаптироваться и внести соответствующие изменения. Это становится достаточно критичным.
При наличии опытного аналитика или двух аналитиков, владеющих хотя бы на минимальном уровне no-code, low-code и нужными системами, задача становится гораздо проще.
У нас, например, нужно было интегрировать две разные ИИ-платформы. И в таком варианте это оказалось проще, чем проходить классическую цепочку: анализ, проработка какого-то wireframe-прототипа, постановка задачи, архитектура и так далее.
Именно time to market и гибкость внесения изменений стали ключевыми факторами при принятии решения попробовать такой подход.
-
Figma AI – генерация логики и интерфейса
-
Thirdweb и ChainGPT обеспечивают кодогенерацию и no-/low-code инструменты для создания NFT-платформ верификации текстов, графики и медиа через IPFS и смарт-контракты, выделяются масштабируемостью (мультичейн, L2), безопасностью (аудиты, AI-проверка кода) и интеграцией через SDK/AP
Конкретные платформы здесь не самое главное. Они сейчас меняются достаточно быстро. Более того, определенные платформы очень узкоспециализированы. И здесь снова важно помнить оговорку: речь идет о малом и среднем бизнесе, который меньше регулируется по сравнению с корпоративным сегментом.
Критерии сравнения: Команда людей vs ИИ агенты
Так мы подходим к ключевой части – двум парам решений, по которым производится сравнение. Понятно, что с академической точки зрения это не полностью релевантное сравнение. Но тем не менее уже есть данные, которые можно сопоставлять.
У нас есть два разных фокуса, два разных уровня сложности. И в одном, и в другом случае мы начинали с классической продуктово-проектной разработки командами людей, а затем по разным причинам и в разных объемах пришли к использованию ИИ.
На основе этого я решил попробовать построить модель, которая позволила бы более осознанно и методически принимать решения о том, насколько ИИ-агенты могут быть внедрены и где их использование уже становится спорным.
Тема применения ИИ-агентов сейчас возникает в самых разных областях. Но в данном случае я рассматриваю ее жестко с точки зрения разработки.
Критерии сравнения достаточно типовые. Здесь ничего изобретать не нужно. Это сделано в первую очередь для того, чтобы при выборе способа решения задач при построении IT-сервисов и цифровых сервисов можно было опираться на привычные понятия.
Первый критерий – сроки.
Второй – затраты.
Третий – уровень соответствия требованиям заказчика, или, другими словами, уровень удовлетворенности заказчика.
Следующий параметр – возможности роста и по возможности безболезненного масштабирования.
Еще один хорошо известный параметр – обслуживаемость. В него входит внесение изменений, дополнение нового функционала и баланс между затратами и скоростью этих изменений.
Далее – надежность и бизнес-безопасность.
Почему я подчеркиваю именно термин «бизнес-безопасность»? В силу своего опыта и фокуса на малом и среднем сегменте массового рынка я намеренно выношу за скобки безусловно важные вопросы именно информационной безопасности. По этим критериям я ее отдельно не оценивал, хотя понятно, что она крайне важна.
Структура затрат в сроках
Теперь можно перейти непосредственно к модели.
Я намеренно ушел от названий сервисов, поскольку они здесь не нужны.
Для первого, условно простого сервиса, сравниваем колонку «Люди» и колонку «ИИ».
Подбор персонала – два месяца против одной недели.
Понятно, что одна неделя на подбор ИИ – это, по сути, элементарный обзор существующих платформ: их возможностей, технологических характеристик, доступности, стоимости и так далее. То есть достаточно простой отбор внешнего поставщика услуг.
Поскольку решение простое, обучение практически не требовалось.
В итоге на таком сервисе выигрыш с точки зрения сроков просто колоссальный.
По финансам ситуация немного отличается, к ней я еще вернусь.
В более сложном, комплексном сервисе все уже не столь очевидно.
С точки зрения сроков использование гибридной команды людей и ИИ вроде бы выигрывает, но преимущество уже гораздо менее однозначно.
Нужно сразу сделать оговорку: шесть месяцев на подбор персонала отчасти были связаны с нашим ограничением как МСБ. Понятно, что в борьбе за таланты мы были не самым выигрышным и конкурентоспособным работодателем. Это, естественно, привело к некоторому увеличению длительности поиска.
Но это одновременно и определенный флажок: если компания как работодатель не является топом, ИИ может помочь.
По обучению ситуация практически равнозначна. Только в одном случае мы обучаем персонал, а в другом – обучаем персонал работе с ИИ.
По разработке выигрыш ИИ кажется достаточно большим – более чем в два раза. Но он тоже связан со сложностями, которые я обозначил раньше: управлением узкоспециализированным персоналом, который легко может быть перекуплен, и другими подобными факторами. Так что определенные выигрыши есть.
По сопровождению гибридного решения данных пока недостаточно. Это один из очень важных моментов, который еще будет играть роль, хотя в модели этот фактор уже учтен.
Структура затрат в деньгах (тыс. руб)
Вторая составляющая – затраты.
Для несложной системы, несложного сервиса финансовый выигрыш получился почти на порядок. Это не какая-то специально накрученная цифра. Я старался учесть затраты максимально полно. Если посмотреть на структуру расчета, учтены операционные затраты, разработка, обучение, обслуживание, обновление, ремонт и восстановление. Понятно, что не существует сервисов, которые работают безошибочно, поэтому затраты на восстановление всегда нужно закладывать.
Поскольку опыт новый, у ИИ-решения пока ноль отказов за шесть месяцев. Это, безусловно, очень неплохой результат.
Я здесь не обольщаюсь: какие-то отказы, конечно, будут. Но предварительный вывод достаточно понятен: на относительно простых сервисах ИИ дает очень хороший выигрыш.
На комплексных сервисах ситуация снова становится не столь очевидной.
В нашем случае ИИ тоже дает выигрыш, но уже не на порядок. Это все еще достаточно значимая величина. В расчетах указан скорее порядок затрат, а не абсолютно точные цифры, но тем не менее преимущество есть.
Наиболее сложным вопросом сейчас остается стоимость текущего сопровождения и ремонта, поскольку здесь очень велика зависимость от внешних платформ и внешних вендоров.
Сравнительный анализ Люди vs ИИ
Основываясь на этой модели и на первом, пусть пока ограниченном опыте, я попробовал сделать качественную оценку сравнения по срокам, затратам на разработку и остальным параметрам.
Наибольший выигрыш применение агентов в качестве разработчиков дает, очевидно, с точки зрения масштабирования и с точки зрения соответствия требованиям, то есть удовлетворенности заказчика.
На последнем моменте стоит остановиться подробнее.
Почему получается такой результат? Сокращается цепочка реализации. В любой цепочке реализации каждое новое звено увеличивает риск искажения информации. Конкретно в нашем случае остаются, по сути, два звена: заказчик и системный аналитик. Последующих звеньев нет. Это дает достаточно серьезный выигрыш.
Естественно, значительный выигрыш получается и по срокам. Но, как показывают приведенные примеры, преимущество и по срокам, и по финансам существенно уменьшается в комплексных, сложных сервисах.
Пока это скорее гипотезы и предположения, но я думаю, что причина как раз в том, что, как ни называй искусственный интеллект, человеческий разум все равно гораздо лучше охватывает комплексные ситуации. Тем более ситуации, связанные с людьми, клиентами, заказчиками и партнерами.
Что касается надежности и бизнес-безопасности, здесь ИИ вроде бы тоже немного выигрывает. Но я отдаю себе отчет, что это абсолютно частный случай – наш конкретный опыт.
Надежность при применении ИИ-агентов очень серьезно упирается в надежность поставщиков. Более того, поскольку направление новое, существует множество новых компаний-поставщиков, и пока сложно сказать, как они поведут себя на рынке, останутся ли вообще и каков их уровень надежности как поставщиков. Поэтому это, безусловно, одно из узких мест.
Отдельно стоит регуляторика. Здесь человеческий фактор пока остается гораздо важнее.
Ключевые ограничения и риски ИИ «разработчиков»
Можно выделить два абсолютных красных флага с точки зрения рисков применения ИИ-агентов как разработчиков.
Первый – регуляторные ограничения.
В сервисах, на примере которых построено сравнение, регуляторные ограничения объективно минимальны. Там нет персональных данных, нет какой-то чувствительной информации и так далее. Как только подобные требования возникают, возможность применения, особенно внешних ИИ-агентов, естественно, уменьшается.
Второй красный флаг – уже упомянутая высокая зависимость от платформ. Это фактор, который обязательно нужно учитывать.
Есть и так называемые желтые флажки:
-
Предвзятость (bias)
-
Смена парадигмы работы вовлеченного персонала
-
Интеграция с имеющимися решениями
-
Интеграция между платформами ИИ
-
Отсутствие внутренней экспертизы в области ИИ
-
Уязвимости в платформе
-
«Вымывание» junior персонала
Как только мы используем ИИ-агентов, сразу возникают вопросы: на чем их обучали, присутствует ли предвзятость, есть ли у самой команды внутренняя экспертиза. В нашем случае такую экспертизу команде приходилось отдельно прокачивать.
Следующий фактор – риски платформ.
Далее – возможность интеграции с существующими решениями и межплатформенная интеграция.
Все эти риски преодолимы, но при принятии решения их необходимо оценивать. Как и любые другие риски, возникающие при запуске и реализации продукта, их нужно учитывать заранее.
Когда делать акцент на ИИ «команду»
Из первых наблюдений уже можно выделить ситуации, в которых регулятор-ползунок можно немного смещать в сторону усиления ИИ-составляющей.
Прежде всего это любые действия, требующие быстрых результатов: создание MVP, проверка гипотез, быстрая реакция на внешние изменения.
Еще один фактор – высокая волатильность у клиента или высокая волатильность рынка.
ИИ хорошо показывает себя в относительно несложных решениях и в областях, которые не являются уникальными. Здесь логика достаточно понятна. В противном случае ИИ придется, по сути, обучать с нуля, а это уже совершенно другой уровень затрат.
Еще один важный фактор – критичная зависимость от персонала. Здесь возникает достаточно классический вопрос выбора: оставлять компетенции у себя или делегировать.
Такими получились первичные наблюдения. Еще раз подчеркну: ситуация пока находится в процессе развития и меняется очень динамично. Надеюсь, что удастся поддерживать и обновлять саму модель. Думаю, этим будут заниматься многие, чтобы со временем можно было более уверенно принимать решения о том, какие задачи имеет смысл делегировать ИИ.
При этом нужно помнить и об ограничениях самого сравнения. Здесь я рассматриваю только ту часть, которая относится непосредственно к разработке. Вопросы работы с персоналом, мотивации команд и другие смежные области остаются за рамками этой модели.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
