Есть тезис, за повторение которого в последнее время мне регулярно «прилетает» в комментариях и кулуарах: сама языковая модель дает примерно 2% результата ИИ-разработки. Остальные 98% – это обвязка. Инструкции, гейты, процессы, память, люди. Звучит как ересь на фоне последних релизов: модели становятся все сильнее, компании закупают Copilot, Cursor и Claude Code вагонами. Только вот ускорение команд почему-то не фиксируется, и об этом уже пишут не только скептики, но и те, кто эти модели выпускает.

На связи Александр Сахаров,  директор по работе с технологическими партнерами, член правления компании «Диасофт». В Telegram-канале «Департамент разработки» мы провели дискуссию, чтобы проверить эти цифры. К нам пришли эксперты, которые эту обвязку регулярно и с разных сторон тестируют. У нас в «Диасофт» вся эта обвязка – не теория: новая AI Driven версия экосистемы Digital Q как раз и построена на флоте агентов с гейтами на каждом этапе, так что мне было особенно интересно, как на это смотрит рынок.

Небольшой анонс перед началом: в среду, 7 октября, в 18:00 по Москве мы проводим закрытый онлайн-показ AI-driven Digital Q. Это новая версия нашей экосистемы для команд разработки, которая с помощью ИИ ведет проект от бизнес-требований до продакшена. Вот ссылка на регистрацию, а теперь к делу.

Поскольку я сам был участником дискуссии, авторствовать буду только в этом вступлении: дальше говорю цитатами, наравне со всеми. Кому лень читать лонгрид – полная запись на Rutube. Спорить и задавать вопросы приходите на канал «Департамент разработки», там собирается живое сообщество разработчиков.

Модель – это трактор

Александр Сахаров, директор по работе с технологическими партнерами, член правления компании «Диасофт»: 

– Тезис «98 против 2» придумал не я. В явном виде его разобрал Кирилл Меньшов на конференции ЦИПР в докладе AI Disrupts SDLC, а он, в свою очередь, опирался на отчеты Anthropic, крупных консалтинговых компаний и на наблюдения Сбербанка, который целый год смотрел, что происходит с командами. Смысл такой: сама по себе модель – она как трактор. Очень мощная и может сделать реально все. Но чтобы трактор не наломал дров, ему нужны грамотный водитель, механик, агроном, правильно построенный гараж и станция технического обслуживания. В американской терминологии это называется harness. Сбербанк вводит понятие integrated development platform, мы называем это development ecosystem. Идея одна: сама по себе модель не так важна.

Если речь про разработку «на коленке», про свадебные сайты и простые задачи, то можно дать поручение любой модели, и она все сделает, и все будет хорошо. Но у корпоративной разработки, у компаний из топ-1000, требования серьезные. Недостаточно просто написать софт. Его нужно правильно задокументировать, проконтролировать весь инфобез, по некоторым частям получить сертификацию ФСТЭК, что-то поставить в реестр российского ПО, пройти другие аттестации. Есть целый ГОСТ по безопасной разработке. Если скормить такую задачу голой LLM, она молодцом отработает и даже выдаст рабочий результат. Но возьмем простой пример: нужна подсистема управления ролевым доступом, причем не просто по требованиям ФСТЭК, а с сертификатом ФСТЭК на эту подсистему. LLM возьмет и напишет ее с нуля. Чтобы она этого не сделала, ей нужна инструкция: систему управления пользователями не пиши, возьми готовую вот здесь. Если внимательно посчитать, таких инструкций оказываются сотни, и группируются они по двум десяткам ключевых направлений: информационная безопасность, горизонтальная масштабируемость, работа с данными, с бизнес-требованиями, с ТЗ, с архитектурой, со сборкой, интеграционные, нагрузочные и регрессионные тесты, тесты обратной совместимости, контроль юнит-тестов. Вот все это и есть та самая обвязка, которая позволяет не вслепую запускать задачу в модель, а запускать ее в процесс. У нас сегодня порядка сорока агентов, которые пропускают задачу через процесс, соответствующий всем требованиям к созданию ПО. На выходе получается не просто работающий код, а код сертифицированный, пригодный для сопровождения и для размещения у требовательных заказчиков вроде министерств и закрытых ведомств. Чтобы создать такую экосистему агентов, работала команда порядка двадцати человек, и полный перевод на агентскую схему занял шесть месяцев. Сегодня мы можем взять любой набор требований и отдать их первому агенту. Дальше он запускает два десятка других: те уточняют требования и бизнес-процессы, прорабатывают подсистему безопасности, на каждом этапе общаются с аналитиками, архитекторами и тестировщиками, создают сценарии и прогоняют все через DevOps. На каждом этапе стоит огромное количество квалити-гейтов, и этими гейтами тоже управляют агенты. Наше утверждение – в том, что в отсутствие такой экосистемы продукт получается пригодным разве что для очень малого бизнеса. Отсюда и мысль про 98% обвязки и 2% LLM. Отдельно стоит сказать про токены. Если дать волю уважаемой LLM, она сожрет их у вас только так. Еще на ходу создаст СУБД, перепишет операционку, взломает пару сайтов, а потом скажет: извините, я этого не хотела. Но токены уже потрачены, и вернуть их нельзя. В сообществах разработчиков таких примеров с горами потраченных токенов – масса.

Чужой дом или своя уборка

Тим Зинин, управляющий партнер компании «Зинин, Штурбин и партнеры»: 

– Обвязка, или, как привычнее, харнес, действительно решает все. Но я бы подсветил другую проблему: большая часть энтерпрайза приходит к необходимости разработки собственного харнеса. Можно начинать с опенсорсных инструментов и кастомизировать их, можно работать с решениями Anthropic, если они доступны в вашем регионе. Но, думаю, значительная часть коллег сталкивалась с ситуацией, когда вы просто не можете сделать какие-то вещи: банально зарегистрироваться на сайте или выполнить действие, которое, по мнению вендора, вы делать не должны. Молчу уже о том, что модель может сама переключаться с флагманской на попроще. Это становится реальной болью, когда харнес не заточен под вас. Показательный пример – «Билайн»: здесь отдельно стоит вопрос о запуске ИИ-продуктов, и коллеги идут по пути разработки собственного харнеса. Да, это чревато огромным количеством «боли» в поддержке и отладке, но зато вы уходите в прекрасный мир, где можно учесть и 152-ФЗ, и все остальное. Поэтому с тезисом я полностью согласен, но куда интереснее вопрос, как харнес должен работать именно под вас и как вы его кастомизировали.

Александр Сахаров: 

– Всегда можно сказать, что ваши настройки нам не очень подходят, мы хотим немного другие. Спорить с этим бессмысленно. Крупные компании вроде «Билайна» могут позволить себе и 20, и 30 человек, которые сидят и донастраивают харнес: на фоне их прибыли потраченные на это деньги ни на что не влияют. Но когда мы говорим про компании, где каждые пять человек на счету, строить обвязку самим очень дорого. Поэтому наш подход такой: скачиваешь с сайта, и все уже настроено. А поскольку вся харнес-обвязка – это человекочитаемые текстовые файлы, их можно сколько угодно править, усложнять, упрощать, удалять и добавлять. Она пригодна для самостоятельного развития. Это как сравнить строительство дома и уборку в комнате. Понятно, что построить дом немного сложнее, но убирать в комнате, делать ремонт и двигать стены мы все прекрасно умеем сами. Мы даем построенный и преднастроенный дом, а вы в нем можете поменять планировку – да хоть ванну на кухне поставить.

Мария Филатова, предприниматель, эксперт в сфере цифровых технологий и AI, сооснователь ряда технологических проектов: 

– Я, честно говоря, за правильное введение определенных ограничений, и платформа меня ни в чем не ограничивает. Во-первых, когда есть платформенные инструменты, команда, которая занимается этим много-много лет, уже проделала за тебя, как минимум, половину пути: собрала нужные LLM под «капотом», обучила, построила необходимые базы данных, настроила логику этого несчастного RAG, без которого даже загруженные данные нормально использовать не получится. LLM, эта умная модель, наш процессор, – на самом деле маленькая часть всего, что дает необходимый результат бизнесу. Неважно, малый он, средний или крупный. Просто у крупного больше возможностей для собственной разработки, а малый и средний могут использовать готовые преднастроенные решения: сценарии уже есть, агенты умеют работать и понимают контекст, людям не надо заново прописывать системные промпты и выстраивать контекстную логику, базовые интеграции сделаны за них. Это выгода для всех: и для разработчиков, и для компаний, которые могут это применить. Тот же «Билайн» или, не знаю, Газпром – почему бы не использовать преднастроенную платформу, а дальше играться с ней как угодно: дообучать, подключать другие данные, развивать эту историю. Мне очень понравился один пример. Что такое линия? Банальный вопрос. Но обратитесь к математике, физике, географии, астрономии, и ответы будут разные. Спросите LLM, что такое линия, и она даст ответ в зависимости от того, на чем училась. Ответ даже будет верным. Но если мы не заложим определенные правила, не зададим контекст, не объясним, для чего и где хотим это применять, результата мы не получим. Поэтому я поддерживаю платформенную историю: предварительная разработка командами, которые понимают, как это нужно делать, необходима для полноценного бизнес-результата.

Рынок в огне, но не из-за LLM


Диана Распопова, эксперт по управлению ИТ, техническому due diligence и эффективности ИТ-функции: 

– Сегодня рынок разработки сильно меняется в сторону ИИ. Но рынок бьется в конвульсиях достаточно давно, и с LLM как таковой это не сильно связано . Если взять докризисные времена, тот же бигтех скупал стартапы в невероятных объемах, просто потому что вдруг пригодится. В какой-то момент эти стартапы посокращали и позакрывали, куча народу вывалилась на рынок со словами: мы в огне. С тех пор, собственно, ничего не поменялось. Есть компании, которые предоставляли легко заменяемые сервисы: не очень качественные или сделанные достаточно «дешевыми» базовыми специалистами. Вот их действительно можно сейчас заменить ИИ. Если нужны простые сайты, зачем платить тысячи рублей людям, которые в общем и целом сделают то же самое, что модель сделает за час, если рассказать ей правильную историю.

Но здесь встает другой интересный вопрос. Помимо обвязки мы игнорируем тот факт, что многие компании почему-то решили: ИИ может заменить этих самых машинистов с точки зрения качества. То есть можно обойтись менее квалифицированным персоналом, взять кого-то подешевле и попроще, дать ему хороший инструмент, и человек среднего уровня со всеми задачами справится, и вообще это будет классно. Раньше мы брали команду архитекторов, и она стоила нам дорого, а теперь берем условно какого-нибудь начинающего мидла, это стоит недорого, а все сделает ИИ. Так вот это заблуждение, потому что мы как раз возвращаемся к контекстам и всему остальному. Если человек не знает, как правильно сформулировать задачу, как ее провалидировать, как в принципе ее поставить, то говорить о суперкачественном результате на выходе не приходится. Это даст ровно то, что даст: те ограничения, которыми вы владеете, ограничения вашей системы, ваших процессов и ваших людей. Не более того.

Горлышко уезжает вправо

Константин Рыбаков, руководитель направления ИИ-разработки компании BIV:

– В базовом использовании ИИ дает максимальный прирост индивидуальным разработчикам: они значительно повышают свою эффективность и могут делать простые проекты и небольшие сервисы, которые быстро выводятся на рынок. Энтерпрайз –  гораздо более сложная система, требующая куда больше ограничений и выстроенных процессов, причем не только в рамках отдельно взятой команды, но и компании в целом, и выстраивать их приходится шаг за шагом. Этот «паровоз» только начинает набирать обороты. Чтобы запустить адаптацию в компании, необходимо описать все спецификации, процессы и методологии, добавить эти описания в харнес, поставить гейты со всеми проверками и разными уровнями валидации на разных этапах. Только после этого можно говорить, что ИИ ускоряет энтерпрайз-разработку. В противном случае можно остановиться на любом из этапов и получить  проблем больше, чем эффекта.

При этом обвязка ускоряет базовые процессы, потихоньку смещая «бутылочное горлышко» на более поздние этапы. Если сейчас узкое место – сама разработка, под которую раньше пытались набирать все больше сотрудников, потому что их постоянно не хватало, то обвязка переместит это «горлышко» чуть дальше: на проверку пул-реквестов, выкатку в релиз, тестирование. Поэтому нужно строить полный агентский цикл, где агенты работают на всех этапах, начиная с аналитики: спецификация передается на разработку, потом на тестирование, выполняются автотесты, идет раскатка на стенды, и все это с human in the loop, с подтверждением и акцептацией каждого отдельного этапа сотрудниками. А сотрудники должны понимать контекст бизнеса и нести ответственность за тот блок, который для них подготовил агент.

Диана Распопова:

– Есть еще пара моментов, на которые стоит обращать внимание. Первая интересная штука – вопрос разделения контуров. Нам кажется, что пустить агента в дев-контур совершенно безопасно. Угадайте, у скольких разработчиков продовые токены зашиты где-нибудь на локальной машинке. Даже если агент работает как будто бы локально, вопрос, что он оттуда может достать и что поудалять с какой-нибудь продовой базы, остается открытым. А вот вторая история: ботлнек действительно очень сильно смещается вправо, в сторону ревью и приемки. И здесь возникает вопрос навыка. Прослойка тимлидов и техлидов, которые всегда занимались код-ревью, то есть осознанной вычиткой и приемкой того, что делают программисты, а не просто мержем, не очень-то большая. У обычного программиста навык ревью не факт что настолько прокачан. И не факт, что вы сможете обеспечить качественное вливание в свое легаси или хотя бы понимание, что LLM действительно сделала то, что вы хотели, если такого навыка у разработчиков нет.

Легаси: у агента нет материала для харнеса

Андрей Расщепкин, Delivery Manager компании GMI:

– А что, если генерация кода перегружает ревью? Может, ее стоит сознательно ограничить? Нет, сознательно ограничивать количество генерируемого кода не нужно. Это как вместо того, чтобы учиться управлять автомобилем, просто «придушить» его до пяти лошадиных сил и минимальной скорости. Немного странно это. Нужно менять подходы к разработке. Модель возможна, когда мы загружаем ТЗ, субагенты выполняют задачи и все это доходит до продакшена. Я в это верю и знаю, что говорю. Но, к сожалению, на рынке уже полно софта, который разрабатывался и продолжает разрабатываться людьми. Там тонны легаси и контекста, которого LLM не знает. И здесь как раз нужен харнес, только он должен не просто иметь доступ к информации, он должен сам себя поддерживать. Мне кажется, в этом сейчас основная загвоздка. Мы должны не просто давать агенту как можно больше информации,но и давать ему возможность эту информацию генерировать и использовать. Все смещается с менеджмента конкретных фич и пул-реквестов к менеджменту общего контекста и памяти агента в компании, ну, и всех его субагентов. Вот тогда это дает прирост продуктивности.

Схема с флотом агентов прекрасно работает на новых проектах. Но представьте себе компанию, которая десятилетия разрабатывает аналитическую систему: сотни разработчиков, длиннющая история гита, куча микросервисов. Безусловно, я верю, что они все документировали. Но все мы люди: что-то забываем, где-то ошибаемся. Какие-то решения принимались и не фиксировались в системах, разработчик на ходу делал не так, как написано в документации, потому что требования успели поменяться. И мы имеем полным-полно продуктов, которые должны развиваться быстрее, но просто не могут, потому что нет материала для харнеса. Сайт для свадьбы – идеальный обратный пример: там память вообще не нужна. Говоришь, какие фотки разместить и когда ивент, даешь агенту доступ к серверу, и он сам все задеплоит, скорее всего даже DNS пропишет. Сложный проект с нуля агент тоже может сделать. Но просто взять легаси, уволить двадцать разработчиков, которые делали продукт пять лет, и заменить их агентами – вот в это я не верю.

Диана Распопова:

– Это вообще классическая ситуация. Когда вы десять лет разрабатываете какую-то систему, у вас куча легаси, и оно, скорее всего, не документировано от слова «совсем», потому что разрабатывали так: «скорее-скорее», «быстрее-быстрее». А там, где документация есть, она очень часто не соответствует решению или в принципе неактуальна, потому что потом что-то исправляли. И если вы такую документацию сгрузите в контекст, получите много всякого интересного, что по вам потом стрельнет.

Андрей Расщепкин: 

– Что опаснее: модель без корпоративного контекста или модель, уверенно использующая устаревший контекст. Выбор без ответа, ведь результат мы хотим получать здесь и сейчас. Модель без контекста при попытке сделать что-то новое, скорее всего, сломает что-то существующее. Модель с устаревшим контекстом будет на два шага позади разработки и тоже не сможет ничего сделать. Память и ее менеджмент – краеугольные камни LLM-разработки, и какого-то выбора здесь сделать невозможно. Причем, даже если ошибочное решение изначально есть в контексте, удалять его оттуда не стоит: память должна хранить все принятые решения, потому что полностью вычистить легаси из кода невозможно. Я еще ни разу не видел, чтобы какая-то команда победила все, что было до нее. И агент тут – не спасение: легаси никогда не будет вычищено до конца, да, наверное, и не должно.

Обвязка консервирует ошибки или спасает от среднего по гитхабу

Александр Сахаров:

– По сути, никаких 98% нет, есть плохо выстроенная инженерная культура, которую ИИ просто подсветил. Тут не с чем спорить. А обвязка – способ законсервировать собственную архитектуру. Нужно понимать, что сами по себе 98% и 2% вообще ничего не значат: цифры написаны «от балды», и показатели никак не измерялись. Можно говорить: 90 на 10, можно – 60 на 40. Смысл общий. Повторю, это не мое мнение, а мнение Anthropic, Сбербанка и разных Boston Consulting Group с Gartner, я лишь на него опираюсь и вижу подтверждения в собственной работе. Что касается консервации, то да, мы действительно стараемся повторять нашу архитектуру. Мы знаем, что если сделать фундамент, на нем можно построить два этажа. А если строить два этажа без фундамента, то через два года дом «съедет» на участок соседей. Возможно, это ошибочные знания, но мы заставляем наших агентов учитывать стандарты архитектуры, в которые верим. Мы также знаем, что у нас под землей находится метрополитен, и если копать лопатами на глубину десять метров, есть вариант прокопать, сесть на поезд и покатиться, как в фильме «Люди в черном». Поэтому мы говорим агентам: нельзя нарушать архитектурные принципы и правила работы в наших системах. Обычно я привожу такой пример. Есть Германия – с дорогами, на которых очень строгие правила. И есть Индия – с дорогами, на которых правил нет. Где средняя скорость выше? Думаю, все знают, что в Германии. В Индии по дороге может очень комфортно пройтись корова, но все при этом будут стоять в пробках. То же самое здесь: LLM, которая не обращает внимание на структуры, может зафигачить ту корову. Будет очень красиво. Но обычно в больших проектах мы запрещаем нарушать наши архитектурные стандарты, и это как раз то, что называется professional experience, профессиональная компетенция и опыт. Возможно, мы отстали от жизни, но 35 лет работы с крупнейшими банками говорят об обратном.

При этом мы вовсе не ограничиваем модель в новых архитектурных идеях, наоборот, ждем от нее предложений. Помните, в какой-то момент появилась роль product owner. В «Авито», в крупном ритейле, в банках на каждый раздел мобильного приложения есть свой продакт: один работает, чтобы депозиты лучше начислялись, другой – чтобы бонусная система лучше работала. Так же и у нас: у каждого агента есть product owner, задача которого – постоянное развитие, continuous improvement. Он всегда озабочен тем, что улучшить в действующем агенте, и заинтересован в поиске новых идей. Если агент предлагает что-то хорошее и это хорошее проходит апробацию, мы с радостью это применяем. Причем он сам проверяет, сам тестирует, сам запускает A/B-тест, сам снимает с него показания и приходит с готовым результатом: ребята, я тут не фигню предложил, а целое исследование за вас сделал, пока вы были на выходных. Давайте распространять на весь проект.

Андрей Расщепкин: 

– Возможно, наши опасения по поводу ограничений агента чуть преувеличены. Все-таки LLM, какой бы развитой она ни была, – это большая модель по предсказанию наиболее ожидаемого продолжения текста. Когда мы просим агента что-то сделать, он обычно и предлагает наиболее ожидаемый вариант. Просишь что-то для «фронта» – он возьмет скорее React, потому что таких репозиториев большинство. По этой причине, кстати, новые фреймворки сейчас испытывают трудности с набором критической массы, чтобы вообще зафиксироваться. С архитектурными решениями аналогично: да, у агентов есть поиск, они стараются находить решения в интернете, но в целом склонны к устоявшимся, не раз опробованным вариантам. С чем я и сталкивался лично: прошу агента сделать страничку, а он зачем-то добавляет туда сайд-меню, хотя его никто не просил. Все потому, что в репозиториях, на которых он обучался, сайд-меню было. Просишь кликабельный прототип – он добавляет дашборд с графиками. Зачем? Непонятно. Но дашборд с графиками встречается в тысячах репозиториев, и это ожидаемый результат. Поэтому бояться, что мы избыточно ограничим агента и отрежем его от инновационных решений, мне кажется, не стоит. Наоборот, агента нужно подталкивать к инновациям, иначе сам по себе он останется на среднем уровне.

Вайб-кодинг, SMB и цена «на 85% готово»

Тим Зинин: 

– Если мы говорим про уровень энтерпрайза, я со многим согласен. Когда к тебе на главную страницу сайта приходят десятки тысяч человек, права на ошибку просто нет, и строгие правила с железобетонными гайдами здесь могут и должны обезопасить бизнес. Но мне в этой картине не хватает малого бизнеса. Потому что, если посмотреть правде в глаза, за последние полгода харнесы сами по себе сильно упростились. Claude Code появился когда? Полтора года назад. И за это время он проделал путь от инструмента разработчика до инструмента предпринимателя. Посмотрите на C-level, на людей, вообще не связанных с разработкой: через упрощенные версии харнесов они решают свои задачи по юнит-экономике или подают отчетность в какой-нибудь экзотической стране. У малого и среднего бизнеса, в отличие от энтерпрайза, право на ошибку есть, а с ним и возможность постоянно тестировать новые гипотезы. Это прерогатива молодого бизнеса, одиночного предпринимателя, новой волны людей-корпораций, которые сейчас появляются, и это очень интересный феномен. Являясь таким человеком, вооруженным AI, ты можешь тестировать гипотезы ежедневно. Да, там может быть огромное количество шит-кода, но ничто не мешает выбрасывать его в рынок и проверять идеи. Так что это просто разница восприятия: корпорации очень рискованно впускать агентскую разработку без определенных правил, а компанию размером до двухсот человек такие инструменты только ускоряют.

Причем не сказать, что все крупные клиенты дружно уходят на платформы с предустановленной обвязкой. Крупные предпочитают «пилить под себя» или в очень долгом процессе согласований искать компанию, которая решит им нерешаемые проблемы. Средний лидтайм в этой индустрии – полгода, и повезло, если успели все согласовать между возвращением с новогодних, а потом с  майских каникул. А SMB тем временем множится. За счет этого безумия микростартапов и эффективности, которая появилась у малого бизнеса, рынок энтерпрайза просто становится меньше, и со стороны это выглядит как кризис. Хотя если немного сместить прицел и посмотреть на небольшие компании – там бурный рост.

Диана Распопова: 

– Прототипирование действительно стало легче. Раньше, когда нужно было просто проверить гипотезу и собрать MVP, приходилось идти к программистам и заказывать разработку, которую потом все равно переписывали, потому что собиралась она «быстро-быстро» и на «коленке». Сейчас то же самое на «коленке» можно сделать с агентом, если вы умеете задавать ему то, что хотите получить. Но тут вы должны быть уверены, что понимаете свой definition of done по каждой фиче, а это совсем не факт. А что я хочу получить? А, может быть, я и не знаю, что я хочу получить. Начинается свобода творчества, и если  за этим не сидит профессионал, вы можете не получить ничего, потому что просто не понимаете, как спросить и как задать рамку. Поэтому вопрос про индустрию под угрозой правильнее ставить так: какая часть индустрии под угрозой. Хороший дорогой аутсорс, который умел работать с энтерпрайзом, MVP и раньше почти не делал: клиент не хотел платить миллионы рублей за то, что в общем и целом будет выброшено. MVP несли маленьким студиям и фрилансерам, там делали за копеечку, а большие деньги платили уже потом, если эта история выстрелила, и ее переделывали в работающую систему по хорошим правилам. Для крупных студий ничего не поменялось, туда все так же идут. А для маленьких студий открывается другое окно возможностей. Потому что если я не понимаю, что такое хостинг, что такое DNS, как в принципе работает сайт, как собирать персональные данные, и уж тем более ничего не знаю про 152-ФЗ, то с вероятностью 99% после взаимодействия с LLM я куда-нибудь «присяду», и, возможно, надолго. Есть огромная прослойка людей, которым нужен кто-то, кто проконсультирует и объяснит, как это работает. Вот в таких консультантов маленькие студии, скорее всего, и переквалифицируются.

Андрей Расщепкин:

– Прототипы действительно появляются быстрее, и я рассматриваю это с двух сторон. С одной стороны,  продакт-менеджерам внутри команд стало сильно проще делать прототипы и показывать их разработке. Раньше писали документацию, потом дизайнер делал прототип, потом это все ревьюили разработчики. Сейчас менеджер может просто открыть Claude, в пару кликов подключить GitHub и попросить сделать полностью кликабельный прототип новой страницы или нового флоу, описать ограничения, самому все протестировать и отдать в разработку вполне рабочий концепт. И это прекрасно. Но с другой стороны, к нам приходят клиенты, которые что-то собрали на Replit, Lovable и прочих агентных системах, оно плохо работает, и рассуждают они с такой позиции: тут на 85% все готово, вам нужно буквально пару багов пофиксить. При этом никакой харнес там не использовался, нет ни тестов, ничего. Они уперлись в лимит системы: проект разросся, они просят добавить фичу, новая фича ломает старые. За каждый запрос условный сервис выставляет счет на 15 долларов, и люди уже сидят и нервно смотрят, как там что-то крутится: минус 15 долларов, и теперь не работает что-то новое. Поэтому, в моем понимании, в такие продукты будут встраивать только больше и больше обвязки, чтобы ими могли пользоваться менее технически квалифицированные пользователи.

Харнесы не умирают, они упрощаются

Константин Рыбаков: 

– Если обвязка – это просто текст, который скармливают модели, не впитают ли модели ее со временем целиком, сделав ненужной? В базовом случае, на типовых задачах и простом MVP без привязки к платформам и решениям, которые уже есть в компании, надстройки и обвязки над агентами, возможно, действительно не нужны. Но если рассматривать задачу чуть шире и учитывать ограничения компании, существующие библиотеки, принципы и методологии, которые необходимо применять, без обвязки уже никуда. Здесь на помощь приходят наборы скиллов, которые мы потихоньку добавляем в свой инструментарий: это просто текстовое описание, которое добавляется в контекст, и модель следует методологии, описанной под конкретный процесс. Такие скиллы могут решать шаблонные задачи уже в рамках существующего проекта, понимая его контекст. И отдельный момент – токены. Без специальных решений модель будет каждый раз грепать весь код и смотреть, что в нем есть и какие там классы, значительно потребляя токены, по подписке или за оплату. Это просто сжирает содержимое кошелька. А добавив, например, плагин вроде Super Memory, мы упрощаем модели поиск по нашей кодовой базе и значительно повышаем точность до насыщения контекста.

Александр Сахаров: 

– Прелесть всей этой истории в том, что скиллы лишь в редком случае представляют собой специализированную модель. В большинстве своем – это просто написанный контекст с инструкциями, хоть на русском языке. Поэтому все открыто и достраивается: можно вставить, добавить, создать, подключить что угодно, никакой проблемы в этом нет. Я, честно говоря, последние пару месяцев был больше погружен в проекты, но думаю, что где-то уже появился маркетплейс скиллов, что он уже большой, и там уже можно все скачивать и подключать.

Тим Зинин: 

– Мы находимся в очень динамичной среде, где определения появляются так же быстро, как движется сама технология. Но если ставить знак равенства между обвязкой и харнесом, то отказаться от нее невозможно, и действительность доказывает обратное: все идет к упрощению взаимодействия. Возьмите Perplexity. Вам не нужно понимать, как выглядит терминал и как устроены CLI-интерфейсы, чтобы подключить через MCP свой Telegram, воткнуть туда же WhatsApp и организовать первую линию поддержки на двух мессенджерах, не выходя из браузера. Ноль разработки, немножко настройки – с этим справится подросток, сотрудник финотдела или бухгалтер. Можно ли задавать свою обвязку? Да, и это довольно просто. У меня есть собственный харнес Zinin CLI: инструмент, который ставит предпринимателю в терминал три других харнеса и заодно дает мануал, как ими пользоваться. Сделать такую штуку при средних инженерных знаниях можно за вечер. Нужно ли? Тот же «Билайн» отвечает «да» и кастомизирует опенсорс под себя, потому что так проще передавать скиллы на уровне энтерпрайза. Можно ли в сложном проекте обойтись вообще без харнеса? Тут все упирается в definition of done, то есть в то, какой это проект. Если мы делаем десятки микросайтов, наверное, можно. Но зачем, когда проще работать с роем субагентов и агентским менеджментом? Харнес и LLM – это как две опоры в жизни агента. Можно ли отказаться от LLM в агентской разработке? Ну, наверное, можно посадить десять программистов, которые будут работать вместо нее. Но зачем? Так что харнесы никуда не денутся, они просто станут проще. Скорее всего, мы идем к взаимодействию через какой-то совсем простой интерфейс, вербальный или нейробиологический – время покажет. А пока достаточно зайти в любой чат, связанный с вайб-кодингом, простите за слово, и посмотреть, что происходит: люди без опыта разработки врываются в предпринимательскую жизнь. На мой взгляд, это очень позитивные изменения.

На этом дискуссия и закончилась: о цифрах можно спорить, о направлении – уже вряд ли. А на чьей стороне ваши проценты – расскажите об этом в комментариях.