e-comEXPERT 
Тендеры и лиды
Информация
Еще полгода назад многие компании воспринимали нейросети как инструмент, способный радикально изменить экономику разработки. После первых экспериментов эффект действительно был заметен: новые функции появлялись быстрее, исправления занимали меньше времени, а команда могла закрывать больше задач за тот же рабочий день.
Вместе с этим изменились и ожидания рынка. Если раньше MVP за несколько месяцев воспринимался как нормальный срок, сегодня бизнес рассчитывает получать первые рабочие результаты значительно быстрее. И нейросети действительно позволяют эту скорость обеспечить.
В e-комЭКСПЕРТ мы тоже активно используем ИИ в разработке и видим этот эффект на практике. Например, у нас есть формат экспресс-прототипирования: за 2-3 часа вместе с клиентом мы можем собрать готовый макет будущего продукта и проверить ключевые идеи еще до начала полноценной разработки.
Но одновременно видим и другую сторону: результат сильно меняется в зависимости от масштаба и сложности проекта, его архитектуры, организации работы с контекстом и опыта команды.
Отсюда возникает логичное ожидание: если ИИ уже ускоряет разработку, то по мере роста проекта его ценность должна только увеличиваться.
Но сохранить этот эффект удается не всегда. По мере развития проекта растет количество связей и зависимостей, отдельные задачи снова начинают занимать больше времени, а команде приходится чаще проверять и дорабатывать результаты, полученные от нейросети.
Со стороны это может выглядеть так, будто сама модель стала работать хуже. На самом деле меняются условия, в которых она используется. Проект становится сложнее, для принятия решений требуется больше контекста, а результат все сильнее зависит от того, как организована работа с ИИ.
Почему на небольших проектах эффект от ИИ заметен сразу
Представим типичную ситуацию для automotive-бизнеса. Компания запускает новый интернет-магазин автозапчастей: каталог, корзина, оформление заказа, личный кабинет и интеграция с 1С. Проект относительно компактный, большинство модулей напрямую связаны друг с другом, а логика системы еще не успела обрасти исключениями и нестандартными сценариями.
На этом этапе искусственный интеллект работает практически в идеальных условиях. Чтобы реализовать новую функцию, ему достаточно проанализировать ограниченное количество файлов и понять несколько взаимосвязей между ними. Например, если разработчику необходимо изменить логику оформления заказа, Нейросеть зачастую достаточно увидеть контроллер оформления, модель заказа, несколько связанных сервисов и шаблон интерфейса. Общий объем такого контекста может составлять всего несколько десятков файлов.
Именно поэтому модель способна не просто дописывать отдельные фрагменты кода, а понимать общую структуру задачи. Она видит большинство зависимостей, учитывает существующую архитектуру и предлагает решение, которое с высокой вероятностью действительно подойдет проекту. Разработчик получает ощутимую экономию времени, а бизнес — реальное ускорение вывода продукта на рынок.
И именно это формирует ожидание, что по мере роста продукта эффект сохранится автоматически. Но чем сложнее становится система, тем больше усилий требуется, чтобы модель продолжала видеть необходимую для решения задачи картину проекта.
Что меняется по мере развития продукта
Теперь представим ту же компанию, но уже спустя какое–то время.
Интернет-магазин уже давно перестал быть отдельным элементом. За это время вокруг него формируется целая цифровая экосистема: появляются B2B-кабинет для оптовых клиентов, CRM, несколько ERP-систем, WMS для управления складом, мобильное приложение, программы лояльности, сервисы аналитики, динамическое ценообразование, собственные алгоритмы управления ассортиментом и десятки внутренних модулей, автоматизирующих различные бизнес-процессы.
При этом сложность определяется не количеством этих систем, а количеством связей между ними. Если на старте изменение в модуле оформления заказа затрагивало только интернет-магазин, то спустя несколько лет оно может одновременно повлиять на резервирование товара, расчет персональных цен, бонусную программу, обмен с ERP, работу CRM, уведомления клиентов и управленческую отчетность.
В результате меняется сама сложность любой доработки. Теперь недостаточно написать рабочий код — необходимо заранее понимать, как изменение отразится на десятках связанных процессов. Именно поэтому по мере роста проекта основная сложность разработки постепенно смещается от написания кода к анализу зависимостей внутри системы.
Причем значительная часть этих зависимостей не видна в коде. Почему обмен с ERP устроен именно так, какие отчеты строятся на тех же данных, какие договоренности есть с филиалами — эти знания живут в документах, регламентах и головах сотрудников. Чем дольше развивается проект, тем больше таких знаний накапливается вне кода и тем важнее, чтобы они были доступны и людям, и нейросети.
Для руководителя это выглядит как естественное развитие бизнеса. Для AI-инструментов это означает принципиально другой уровень сложности. Если на небольшом проекте модели достаточно разобраться в одном модуле, то в крупной системе ей приходится принимать решения в условиях большого количества взаимосвязей, часть которых остается за пределами доступного контекста. Именно отсюда возникают ограничения, которые начинают влиять уже не на качество отдельных фрагментов кода, а на эффективность разработки в целом.
Первое ограничение становится заметным именно на крупных проектах, где одно изменение затрагивает сразу несколько бизнес-процессов.
Представим ситуацию из automotive-отрасли. Компания решает изменить логику расчета скидок для оптовых клиентов. С точки зрения бизнеса задача выглядит локальной: необходимо обновить правила программы лояльности.
Нейросеть анализирует соответствующий модуль и предлагает корректное решение. Проблема заключается не в качестве сгенерированного кода, а в том, что модель оценивает только ту часть системы, которая попала в текущий контекст.
Например, те же данные могут одновременно использоваться CRM, мобильным приложением, системой аналитики, механизмом расчета бонусов для филиалов и обменом с ERP. Если эти зависимости не были переданы модели, она физически не сможет учесть их при генерации решения.
В результате команда получает код, который выглядит корректным в рамках поставленной задачи, но требует дополнительной проверки всех зависимостей, оставшихся за пределами контекста. Чем крупнее проект, тем больше таких связей и тем сложнее заранее собрать для нейросети всю необходимую информацию.
Поэтому на крупных проектах ИИ перестает быть инструментом, который способен самостоятельно принимать архитектурные решения. Его рекомендации требуют проверки именно потому, что модель не обладает полной картиной системы.
Ограничение №2. ИИ оптимизирует локальную задачу, а не систему целиком
Второе ограничение возникает даже тогда, когда модели передан необходимый технический контекст. Нейросеть решает ту задачу, которую перед ней поставили, но локально правильное решение не всегда оказывается оптимальным для системы в целом.
Представим, что разработчику необходимо ускорить поиск товаров в каталоге.
Нейросеть анализирует запросы к базе данных и предлагает изменить структуру индексов. С технической точки зрения рекомендация выглядит абсолютно обоснованной: поиск действительно начинает работать быстрее.
Однако оптимизация одной функции далеко не всегда означает оптимизацию всей системы. Те же индексы ускоряют чтение, но могут замедлять запись и обновление данных, занимать дополнительное место и увеличивать нагрузку.
В таком случае, проблема принципиально другая: ИИ может располагать всей необходимой информацией и при этом предложить спорное решение. Причем если после этого указать модели на возможные последствия, она вполне может согласиться, объяснить риски и предложить другой вариант. Получается всем знакомая ситуация: «Да, вы правы, извините, это решение действительно может создать дополнительную нагрузку».
Недостаточно просто поставить задачу «ускорить поиск»: необходимо определить какие характеристики системы приоритетны и какой компромисс между ними допустим.
Именно здесь остается роль архитектора: не просто проверить, решила ли нейросеть поставленную задачу, а определить условия, при которых это решение действительно будет оптимальным для системы в целом.
Ограничение №3. ИИ не понимает, почему бизнес нарушает "правильную" архитектуру
Самое сложное ограничение связано уже не с программированием, а с особенностями самого бизнеса.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13752 тендера
проведено за восемь лет работы нашего сайта.
По мере развития продукта архитектура перестает подчиняться исключительно техническим принципам. Наоборот, многие решения принимаются сознательно именно потому, что этого требуют бизнес-процессы.
Например, компания может хранить одну и ту же информацию сразу в нескольких таблицах. Для разработчика это выглядит как нарушение принципа DRY (Don't Repeat Yourself), который рекомендует избегать дублирования данных.
Однако на практике каждая из этих структур может решать собственную задачу: одна используется для онлайн-продаж, другая — для финансовой отчетности, третья — для хранения исторических данных, необходимых для аналитики или аудита.
С технической точки зрения объединение этих данных действительно сделает архитектуру чище. Но с точки зрения бизнеса такое "улучшение" способно нарушить процессы, которые годами формировались под конкретные требования компании.
Нейросеть не знает, почему подобные компромиссы появились в системе. Он оценивает архитектуру по общим инженерным принципам, тогда как опытный архитектор дополнительно учитывает историю проекта, требования бизнеса и последствия каждого изменения для операционной деятельности компании.
Скрытая стоимость использования ИИ
Экономию от использования ИИ легко оценить по скорости написания кода. Но на большом проекте этого показателя уже недостаточно. Важно считать, сколько времени команда тратит после генерации: на сбор контекста, проверку решения, тестирование связанных процессов и исправление побочных эффектов.
Например, нейросеть может сократить реализацию задачи с восьми часов до двух. Но если после этого разработчику потребуется еще несколько часов на ревью, поиск затронутых зависимостей и исправления, реальная экономия окажется значительно меньше.
Поэтому на практике полезно отслеживать не только скорость генерации, но и несколько других показателей: сколько AI-задач возвращается на доработку, сколько времени занимает ревью сгенерированного кода, как часто изменения затрагивают неучтенные модули и сколько времени разработчик тратит на подготовку контекста для нейросети.
Если эти показатели начинают расти вместе с проектом, переход на другую модель сам по себе проблему не решит. Это сигнал, что пересматривать нужно уже не инструмент, а сам процесс работы с ИИ.
Именно здесь становится заметна разница между использованием нейросети как генератора кода и AI-ассистированной разработкой как выстроенным процессом.
На больших проектах недостаточно просто дать нейросети доступ к репозиторию и ожидать, что она самостоятельно разберется во всех связях системы. Чем сложнее продукт, тем важнее то, как организована работа с ИИ.
Первое, что для этого нужно, — структурировать знания о проекте. Архитектура, связи между сервисами, бизнес-правила, особенности отдельных модулей и принятые ранее решения не должны существовать только в головах разработчиков. Их необходимо описывать так, чтобы для каждой задачи нейросеть могла получить именно тот контекст, который ей нужен.
Второй момент — сама архитектура. Систему по возможности стоит разделять на независимые блоки и сокращать количество связей между ними. Тогда для изменения конкретной функции нейросети не приходится анализировать весь проект целиком: достаточно контекста нужного модуля и информации о его взаимодействии с остальной системой.
Но даже хорошо организованный контекст не решает задачу сам по себе. Важно, кто работает с ИИ. Инженер должен определить границы задачи, понять, какие зависимости она затрагивает, подготовить необходимый контекст и проверить решение там, где ошибка может повлиять на другие процессы.
В нашей практике есть два проекта, которые хорошо показывают, где на самом деле проходит граница.
В первом случае ИИ использовался при разработке относительно простого интернет-магазина. Команда активно привлекала нейросеть к поиску и реализации решений, но работа с ней не была системно организована. В результате по мере развития проекта накопились архитектурные решения, которые усложнили дальнейшую поддержку и потребовали дополнительной работы со стороны команды. Именно после этого проекта мы пересмотрели подход к работе с ИИ.
Второй проект значительно сложнее: это система, в которую входят ERP, управление складом и другие связанные компоненты. Здесь AI-ассистированная разработка изначально строится с учетом архитектуры, границ отдельных модулей и контекста, который получает нейросеть. Несмотря на значительно большую сложность системы, количество проблем и ошибок оказалось существенно ниже.
Эти примеры показывают, что масштаб сам по себе не создает ограничения ИИ — он делает их дороже. На небольшом проекте цена ошибки невелика, поэтому отсутствие процесса долго остается незаметным. Но решения, принятые без системы, никуда не исчезают: они накапливаются и проявляются, когда продукт начинает расти. А там, где процесс выстроен, даже сложная система не превращается в проблему.
Отдельный вопрос — кто должен выстраивать такую работу внутри команды. Само направление AI-ассистированной разработки еще достаточно новое, поэтому искать специалиста только по количеству лет работы с конкретной нейросетью вряд ли имеет смысл.
В e-комЭКСПЕРТ мы бы в первую очередь смотрели на инженеров с сильными архитектурными компетенциями. Такой специалист понимает не только код, но и устройство системы целиком: умеет разбирать требования бизнеса, видеть зависимости между компонентами, декомпозировать сложную задачу и заранее оценивать последствия изменений. Именно эти навыки становятся особенно важны при работе с ИИ.
При найме важнее проверять не знание конкретных инструментов, а способ мышления. Вместо вопроса «Какими нейросетями вы пользуетесь?» кандидату можно дать достаточно абстрактную бизнес-задачу и попросить спроектировать решение: определить основные компоненты системы, связи между ними, необходимые данные и возможные ограничения.
Еще один вариант — провести короткую сессию прототипирования. Дать специалисту исходную задачу с неполными требованиями и посмотреть, что он сможет получить за несколько часов с использованием ИИ: какие вопросы задаст, как структурирует задачу, какие решения примет и сможет ли объяснить, почему выбрал именно такой подход.
Такой формат показывает гораздо больше, чем перечень AI-инструментов в резюме. Важно увидеть не то, насколько быстро человек умеет генерировать код, а способен ли он с помощью ИИ превратить неструктурированную задачу в работоспособное техническое решение.
Вместо вывода
Нейросети действительно способны существенно ускорить разработку. На небольших и средних проектах они уже сегодня экономят десятки часов работы программистов и помогают быстрее находить решения.
Однако по мере роста системы ограничением становится уже не столько качество модели, сколько контекст, необходимый для принятия решений: архитектурные правила, описание предметной области, связи между сервисами и накопленные знания команды.
При этом масштаб не создаёт эту проблему, а лишь делает ее заметной. Если работа с ИИ не выстроена, небольшой проект просто позже выставит счёт — в виде усложненной поддержки, долгого ревью и доработок, которые съедают сэкономленное время.
Поэтому вопрос для бизнеса постепенно меняется.
Не «Какой ИИ выбрать?», а «Как организовать работу с ИИ и кто внутри команды сможет выстроить этот процесс?»
И задавать его стоит не тогда, когда проект уже вырос, а с первого дня разработки.
Именно этот переход сегодня становится следующим этапом внедрения искусственного интеллекта в разработку сложных корпоративных систем.
