Роман Кузнецов | Про технологии, ИИ, и не только

Бизнес-стейки у воды 7 августа провели очередную встречу Цифровой Лиги в лучшем формате: гриль, стейки, дым, вода рядом и живые разговоры без лишней официальности. Мы с Михаилом Грохотовым отвечали за мясо. Судя по тому, как быстро все расходилось с доски, получилось хорошо. Люблю такие мероприятия: вроде просто жаришь стейки, а по факту получается нормальный нетворкинг, только без бейджей и сцены. #воскресныйгриль

Бизнес-стейки у воды 7 августа провели очередную встречу Цифровой Лиги в лучшем формате: гриль, стейки, дым, вода рядом и живые разговоры без лишней официальности. Мы с Михаилом Грохотовым отвечали за мясо. Судя по тому, как быстро все расходилось с доски, получилось хорошо. Люблю такие мероприятия: вроде просто жаришь стейки, а по факту получается нормальный нетворкинг, только без бейджей и сцены. #воскресныйгриль

Могут ли ИИ-агенты стоить дороже человека-разработчика? Могут. Сначала кажется, что ИИ почти всегда дешевле живого разработчика. Подписка дешевле зарплаты, запрос к API стоит копейки, модели пишут код все быстрее, логика вроде очевидная. Но вот в чем засада. ИИ продавали как дешевую замену разработчикам, а по факту компания может получить счета за подписки, API, токены, внедрение и контроль качества, которые уже вполне сравнимы с зарплатой инженера. А иногда и выше, что как-то не укладывается в изначальную идею. И тут вопрос: а насколько вообще нынешние цены на токены окончательные? Есть ощущение (и не только у меня), что вендоры часть возможностей продают ниже себестоимости, чтобы задавить конкурентов и китайские модели заодно. Если это правда, то текущие тарифы и лимиты не финальная картина. И первыми это почувствуют те, кто уже плотно завязал процессы на ИИ. Есть и вторая ошибка, довольно распространенная: скидывать моделям вообще все подряд. Такое себе «забивание гвоздей кувалдой». Если не разбираться, какая модель для какой части задачи подходит и сколько токенов на это уходит, ИИ незаметно становится дороже человека. Мы у себя это уже прошли на практике. Код и сложные правки удобнее отдавать Codex, но потом обязательно гонять тесты и делать review, никуда без этого. Для расшифровок лучше локальная GigaAM: там важнее данные и экономика, а не «самая умная» облачная модель. Если нужно второе мнение по тексту, можно дернуть DeepSeek. А где-то вообще хватает Qwen/Ollama локально, ну или просто обычного скрипта, без всякого ИИ. Отдельная головная боль, агентные цепочки. Один агент дергает другого, контекст растет как снежный ком, промпты никто толком не оптимизирует. Формально все работает, все крутится. А по факту счетчик тикает, а пользы почти ноль. AWS, кстати, уже писала про runaway agent loops, когда агент зацикливается и начинает генерировать расходы сам по себе, без чьего-либо участия. Так что да, я бы не стал спорить с тем, что ИИ может выйти дороже программиста. Вполне может. Если поменять понятную зарплату на непонятный расход: без лимитов, без логирования, без выбора моделей под конкретную задачу. И это уже давно не вопрос моды на ИИ. Это просто финансовая дисциплина, обычная, как с любым другим инструментом. Нормальный подход тут не «отдать все агентам и ждать магии». Нужно бюджетировать токены под конкретные задачи, ставить лимиты и понимать, какая модель дешевле и надежнее закрывает конкретный кусок процесса. Тогда ИИ реально остается инструментом экономии. А без этого это просто новый счет. Который сначала выглядит маленьким.

AI-код, которому можно доверять. Контур приемки У нас в Mobecan это стало видно довольно быстро. За один заход AI может поправить несколько файлов, добавить тест и уверенно сказать, что задача готова. Поэтому вокруг AI-кодинга у нас постепенно появился отдельный слой приемки. Не один финальный тест, а несколько проверок, через которые проходит изменение, прежде чем мы считаем задачу закрытой. В нормальном варианте все начинается не с промпта, а с ожиданий. Что должно измениться и как мы это проверим. Где можно, это превращается в TDD. Сначала тест или проверяемый критерий, потом реализация. Где TDD избыточен, остаются acceptance criteria. Дальше код проходит тестирование. Форматирование, analyzer, unit-тесты, widget-тесты. Если задеты внешние данные, отдельно проверяем авторизацию, схему или живое чтение. На этом этапе часто всплывают не большие архитектурные проблемы, а обычные мелочи, которые потом больно ловить руками. Следующий слой - проверка кода. CodeRabbit смотрит diff, ищет потенциальные проблемы, баги, security-риски и странные места в логике. И здесь важна не только сама проверка, а то, что ее делает отдельный процесс с другим контекстным окном. По сути, отдельный агент. Агент, который писал код, уже немного защищает свою логику. А review-агент смотрит на изменение свежее. Не как автор, а как проверяющий. AI поправил код задачи. После unit-тестов мы делаем smoke-тест. Открываем реальный экран, создаем или меняем задачу и проверяем, что она действительно появилась или изменилась. Если всплыла проблема, процесс уходит на исправление. И так несколько кругов, пока проверка не проходит чисто. Только после чистого повторного прохода можно говорить, что задача выполнена. В итоге AI у нас не просто пишет код быстрее. Вокруг него появилась система приемки. TDD, автоматические тесты, review другим агентом, security-проверка, smoke-сценарии и честный финальный diff. Так результат получается предсказуемее и не уходит в цикл бесконечных правок. А как у вас устроена такая проверка?

Как я вовлек команду в ИИ без презентаций: просто показал, где сам экономлю время На одном из созвонов в Mobecan я просто показал команде, что сам уже автоматизировал у себя в работе. Не как презентацию про большое AI-будущее и не как лекцию на тему “всем срочно надо пользоваться нейросетями”. Скорее в рабочем формате: вот была задача, которую я раньше делал руками, а вот теперь часть этой рутины забирает автоматизация. Где-то Codex помогает с кодом и файлами, где-то разбирает документы, где-то собирает черновик, где-то вытаскивает из хаоса нормальную структуру. Часть этих экспериментов уже мелькала в прошлых постах, поэтому для меня это был не демонстрационный стенд, а обычная рабочая практика. И реакция была интересная. Никто, конечно, не сказал: “Все, с понедельника живем в AI-first компании”. Но кто-то зацепился за одну штуку, кто-то за другую. Кто-то спросил, какую подписку купить, кто-то начал уточнять, что установить. Я порекомендовал поставить Codex и начать с простой вещи: взять свою рутину и попробовать снять с себя хотя бы кусок. Дальше люди начали втягиваться сами. Сначала посмотрели, потом попробовали, потом уже начали приносить свои задачи: а вот это можно автоматизировать, а здесь можно ускориться, а такую штуку можно собрать? И следующие созвоны стали уже не про “зачем нам ИИ”, а про “как это применить вот тут”. Мне кажется, это важный момент. Команду сложно вовлечь в ИИ через убеждение, большую стратегию на 40 слайдов или спор со скептиками. Я сам был скептиком вайбкодинга. Да и всей этой AI-темы тоже. Слишком много шума, слишком много красивых обещаний, слишком много людей, которые любую кнопку называют ИИ-агентом. Поэтому когда человек в команде скептически смотрит на очередной “новый подход”, я его вполне понимаю. Но отношение меняется, когда ты сам видишь, что конкретная задача вместо часа начинает занимать 10 минут. Не на чужом кейсе, а на своей рутине, которую ты и так каждый день делаешь руками. Это немного похоже на компьютерную игру: один раз получилось, и ты уже сам начинаешь искать, где у тебя еще повторяется одна и та же рутина. Так я сам постепенно переобулся из скептика в человека, который теперь первым думает: а это можно автоматизировать? Похоже, ИИ в команду лучше заходит не через внедрение сверху, а через первую снятую рутину. Один раз сэкономил время на своей задаче - и дальше уже сам начинаешь искать, что еще можно автоматизировать.

Недостаточно внедрить AI. Нужно собрать систему, которая окупается У нас в Mobecan AI постепенно перестал быть одним чатом в браузере. Я сначала думал про AI довольно просто: есть ChatGPT, есть Codex, есть Claude, есть локальные модели. Ну и дальше вроде вопрос только в том, что открыть под конкретную задачу. Но чем больше мы это внедряем у себя в Mobecan, тем больше видно, что вопрос не в выборе одного инструмента. Например, с транскрибацией. Можно отправлять записи во внешний сервис и платить за каждую обработку. Для пары встреч это нормально. Но если через это начинают проходить созвоны, голосовые, внутренние обсуждения и клиентские записи, быстро появляются два вопроса: сколько это будет стоить на потоке и куда вообще уезжают данные. Поэтому мы подняли локальную транскрибацию через GigaAM. Не потому что хочется поиграться в on-prem, а потому что в такой задаче это просто здравый смысл: данные остаются у нас, а экономика перестает зависеть от каждого запроса во внешний API. С кодом похожая история. Codex сам по себе очень сильная штука, но если просто дать ему проект и сказать "сделай красиво", результат может быть разный. Где-то он реально экономит часы. Где-то уверенно пишет то, что потом надо спокойно вычищать. У нас он начинает нормально работать не сам по себе, а когда вокруг есть понятный процесс: задача, репозиторий, тесты, smoke-проверки, возможность быстро посмотреть diff и понять, что именно изменилось. То есть ценность дает не только модель. Ценность дает связка вокруг нее. Похожая история с продажами. Мы оцифровали кейсы, коммерческие предложения, часть базы знаний, подключаем CRM. И смысл не в том, чтобы сказать "смотрите, у нас теперь AI в продажах". Смысл в более приземленной вещи: быстрее понять входящий лид, не вспоминать руками, делали ли мы что-то похожее, подобрать нормальные кейсы и подготовить основу для ответа клиенту. И вот тут начинается самая неприятная часть. Бизнесу не очень нужна еще одна абстрактная инициатива. У людей и так хватает задач, планов, согласований и внезапных "давайте срочно что-нибудь оптимизируем". Если приходить с фразой "мы можем внедрить вам AI", человек часто слышит не пользу, а новую работу: ему надо вникнуть, сформулировать боль, согласовать бюджет, объяснить руководству, потом еще отвечать за результат. А ему обычно нужно проще: вот здесь стало быстрее, вот здесь дешевле, вот здесь данные не ушли наружу, вот здесь меньше ручной работы, вот здесь можно проверить эффект. Потом я наткнулся на статью Berkeley BAIR про compound AI systems и понял, что они нормальным языком описали то, к чему мы у себя приходим руками. Не одна модель, которая все знает и все делает, а сборка под конкретный процесс. В одном месте запись лучше расшифровать локально. В другом - отдать Codex правку кода, но обязательно прогнать тесты. В третьем - подтянуть кейсы из базы знаний и помочь менеджеру быстрее собрать ответ клиенту. А где-то вообще не нужна модель, достаточно обычного скрипта и нормальной проверки результата. Раньше у меня было ощущение, что LLM - это почти AGI: универсальный интеллект, которому можно отдать любую задачу, и он как-то сам разберется. Сейчас это ощущение прошло. В реальной автоматизации бизнес-процесса LLM - только один из компонентов. Рядом нужны обычные скрипты, оркестратор, доступы, база знаний, CRM, проверки, логика обработки ошибок и человек, который в конце посмотрит на результат и скажет: это можно брать в работу, а это еще рано. И чем дальше мы это пробуем, тем больше видно: ценность появляется не в одной модели, а в сборке из нескольких частей под конкретный процесс. Похоже, AI-проект может не окупиться не потому, что модель плохо отвечает. А потому что все подряд отправили в самый дорогой внешний API, не посчитали поток данных, не встроили проверку и назвали это внедрением. Недостаточно внедрить LLM. Нужно собрать систему, которая окупается в реальной работе.

Нам больше не нужен ваш UI. Дайте MCP-сервер. Сегодня подключил Bitrix24 к Codex через MCP-сервер и впервые нормально почувствовал: мне для части работы больше не нужен интерфейс Bitrix24. Не весь продукт, понятно. Данные, карточки, сделки, статусы - все это нужно. Но заходить в CRM, искать лид, кликать поля и вспоминать, куда они спрятали нужную кнопку, уже не всегда хочется. Раньше я делал это руками. Теперь можно просто написать или сказать задачу агенту, а он уже идет в Bitrix24 через MCP. И тут смешной момент. Мы сейчас делаем трекер задач по личной стратегии. Сначала я через Figma MCP проектировал для него интерфейс: экраны, кнопки, структуру сервиса. Потом мы вместе с Codex накидали MCP-сервер для этого трекера. То есть я сначала сделал UI с помощью MCP, а потом понял, что сам хочу работать с этим сервисом опять же через MCP. Голосом добавить задачу. Попросить разобрать список. Посмотреть, что связано с личной стратегией. Обновить статус. Найти задачи, которые выпали из фокуса. Для этого мне не всегда надо открывать приложение и что-то там раскладывать руками. Потом товарищ Эдуард подсказал посмотреть на Linear. У них это уже официальный сценарий: есть MCP-сервер, который можно подключить к Claude, Cursor, Codex и другим клиентам. Агент может искать, создавать и обновлять issues, проекты, комментарии. И вот тут у меня вопрос стал шире. А UI вообще останется основным способом работать с сервисами? Понятно, что он никуда не исчезнет совсем. Где-то нужно посмотреть картину целиком, проверить глазами, настроить, поправить руками, разобраться в спорном месте. Но если я могу сказать: "найди лидов без следующего шага и подготовь, что с ними делать", мне уже не очень важно, где в CRM фильтр и какая там кнопка. Если я могу сказать: "посмотри, что выпало из фокуса по моей стратегии", мне не обязательно открывать таск-трекер и самому ходить по спискам. Может оказаться, что UI останется для контроля, настройки и сложных случаев. А основная работа с сервисами переедет в разговор с агентом. И тут у меня закралась крамольная мысль (и я проснулся): а в светлом AI-будущем мы вообще будем управлять сервисами через UI?

Клиент пришел не с задачей. Он пришел с мнением ИИ о нашей смете У нас уже несколько раз была похожая ситуация. Клиент присылает техническое задание, написанное с помощью ИИ. Мы его разбираем, даем комментарии, задаем вопросы, считаем предварительную смету. Дальше начинается интересное. Клиент берет наши комментарии и смету, закидывает их обратно в ИИ. А ИИ уже критикует нашу оценку, спорит с комментариями и предлагает клиенту уточнить у нас еще несколько пунктов. После этого клиент возвращается и просит прокомментировать уже не только ТЗ, а то, что ему выдала Ишка. Получается странная коммуникация. Формально мы общаемся с клиентом. По факту в переписке появляется еще один участник, который не отвечает ни за бюджет, ни за сроки, ни за результат, но очень уверенно комментирует все три пункта. И это не единственный сценарий. Был еще кейс: собственник сети авторемонтных мастерских собрал небольшую команду разработчиков и веб-кодеров и через нее двигает автоматизацию бизнеса изнутри. То есть клиент уже не просто приходит к подрядчику с задачей. Он сам собирает вокруг себя маленькую продуктовую команду и двигает автоматизацию изнутри. Похоже, это важный сдвиг. Клиент больше не всегда приходит с пустого листа. Он может прийти с ТЗ от ИИ, мнением ИИ о вашей смете, внутренней командой, прототипом и уже готовым ощущением, сколько все должно стоить. Для агентств это новая реальность, к которой придется привыкать. С одной стороны, клиент становится более подготовленным. Он быстрее формулирует мысли, глубже погружается в процессы, приносит больше конкретики. С другой стороны, появляется новый слой шума. ИИ может уверенно спорить о сроках, не понимая контекста. Внутренняя команда клиента может быстро наделать решений, которые потом сложно поддерживать. А собственник может получить ощущение, что если прототип собрался быстро, то и промышленная разработка должна стоить примерно как вечер экспериментов. Похоже, агентствам придется привыкать. Наша работа все чаще будет не просто “разработать”, а сначала разобрать, что клиент уже успел придумать, проверить через ИИ или собрать своей маленькой командой. Где там польза. Где нормальная гипотеза. А где уверенная ерунда, за которую потом все равно кто-то должен будет отвечать.

Почему у одних с AI получается продукт, а у других только красивая демка? С AI сейчас странная история. Инструменты у всех примерно одни и те же. Cursor, Claude Code, Lovable, ChatGPT и так далее. Но результат почему-то сильно разный. Кто-то собирает продукт, который можно развивать. А кто-то получает демку, которую лучше не трогать после презентации. И дело, похоже, не в том, кто лучше пишет промпты. Я все меньше верю в “просто навайбкодить продукт”. Накидать лендинг, экран, прототип или кусок логики можно. Иногда даже очень быстро и красиво. Но это еще не разработка продукта. Разработка начинается там, где нужно отвечать за результат. Что именно строим, как оно устроено, где данные, какие роли, какая безопасность, как это потом поддерживать и что будет при следующем изменении. У меня это хорошо проявилось при создании тасктрекера личных задач и личной стратегии. Снаружи звучит просто - трекер стратегии. Но как только начинаешь раскладывать, там сразу появляются направления “Я / Семья / Мое дело”, линии развития, OKR, недельные спринты, задачи разных типов, ретро, recovery-сценарии, поддержка, календарь, пользователи, Supabase Auth, RLS. Если просто сказать AI “сделай мне трекер стратегии”, он что-то сделает. Скорее всего даже красиво. Только это будет не тот продукт. Поэтому я пошел другим путем. Сначала user-spec (что пользователь должен получить), потом tech-spec (как это технически устроить), потом декомпозиция на задачи, потом TDD (тесты до кода), проверки и контроль качества на каждом этапе. Если совсем коротко, спека держит смысл, техспека держит архитектуру, тесты держат поведение, контроль качества не дает всему этому развалиться при следующем изменении. И тут есть неприятный момент, про который легко забыть. Я сам несколько раз ловил себя на мысли, что мне лень проверять спеку после правок ИИ. Хочется отдать это на откуп - ну он же умный, сам поправил, наверное нормально. Один раз я уже на этом попался, поэтому теперь гоню эту леность от себя подальше. Спеку все равно нужно читать глазами. Иначе AI может аккуратно поправить документ так, что он станет выглядеть лучше, но смысл немного уедет. А потом этот уехавший смысл поедет дальше - в техспеку, задачи и код. Вот в этом месте и проходит граница. AI может быстро писать код. Но он не обязан понимать ваш продукт так, как понимаете его вы. Если не задать рамку, он будет угадывать. Иногда удачно, иногда нет. Поэтому для меня “вайбкодинг продукта” звучит странно. Навайбкодить можно экран, лендинг, прототип, кусок логики. А продукт начинается там, где появляется ответственность за смысл, архитектуру, тесты, данные и поддержку. И вот тут уже важен не сам AI, а то, в какой процесс вы его встроили.

Вайбкодинг сделал код дешевле. А мышление дороже. У меня сейчас в Mobecan появился вполне практический вопрос: кого нанимать под AI-проекты для клиентов и что вообще писать в вакансии. Раньше на такие задачи логично было искать разработчика. Человека, который умеет писать код, разбираться в API, собирать интеграции, чинить баги и доводить проект до рабочего состояния. Это всё по-прежнему важно, но с появлением AI-инструментов стало понятно, что одного этого уже мало. Код действительно стал дешевле. Не в смысле, что разработка теперь ничего не стоит, а в смысле, что часть работы можно собрать быстрее, чем раньше. Иногда сильно быстрее. Особенно если речь про прототип, лендинг, интеграцию, внутренний инструмент или понятный кусок бизнес-логики. Но проблема сместилась в другое место. Клиенту ведь не нужен код сам по себе. Клиенту нужен продукт, который можно использовать, поддерживать и развивать. А до продукта ещё надо дойти: разобраться в задаче, понять процесс, отделить реальную боль от “хотим AI, потому что все хотят AI”, понять ограничения, экономику и то, кто потом этим всем будет пользоваться. И тут на первый план выходят уже совершенно другие навыки. Кого искать? Разработчика, который умеет думать продуктово? Аналитика, который не боится кода и AI-инструментов? Продакта, который может не только поговорить с клиентом, но и сам собрать рабочий прототип? Пока у меня ощущение, что появляется какая-то новая гибридная роль, но называть её “промпт-инженером” рука не поднимается. Дело в умении разобрать бизнес-задачу и превратить её в нормальную постановку для ИИ и команды. Нужно понять, что именно он должен делать, где брать данные, как проверять результат, где нужен человек в контуре, сколько это будет стоить в эксплуатации и что будет, если модель ошибётся. ИИ может быстро навайбкодить интерфейс, интеграцию или кусок логики, но он не поймёт за клиента, какой продукт ему действительно нужен. Он не разберёт бизнес-процесс и не задаст неприятный вопрос: “А это вообще надо автоматизировать?” И если этого мышления нет на входе, на выходе можно даже не получить красивую техническую демку. Можно получить набор разрозненных AI-фич, которые вроде что-то делают, но в нормальный продукт не складываются. Поэтому я всё больше думаю, что это должен быть системный аналитик с пониманием архитектурных принципов и продуктовым видением. Не обязательно человек, который сам напишет весь код. Но точно человек, который сможет понять задачу, разложить её на систему и объяснить ИИ и команде, что именно мы строим. А как вы ищете "правильных" вайбкодеров на рынке труда?

В Telegram сейчас много контента, но не так много каналов, которые хочется читать регулярно. Особенно в digital, где легко уйти либо в пересказ очевидного, либо в бесконечные советы про «выстройте процессы и делегируйте». Мне ближе другой формат — когда пишут люди из практики. Те, кто каждый день работает с командами, клиентами, сроками, экономикой, правками, факапами и внезапными пожарами. Поэтому я попал в папку с каналами авторов из digital. Там не про идеальный бизнес из презентаций, а про то, как всё обычно выглядит в реальности: где сработало, где ошиблись, где потеряли деньги, где вырулили и какие выводы сделали. Мой канал тоже внутри. Я здесь пишу про разработку, искуственный интеллект и автоматизацию, управление проектами, процессы, клиентов и всё то, до чего часто доходишь только через собственные грабли. Папка для подписки: https://t.me/addlist/xy6z7LKSilA0MGNi Плюс среди подписавшихся разыгрывают подарки: MacBook Neo, Яндекс Станция Лайт 2, JBL Wave Beam 2 Условия для участия в розыгрыше: ➡️ Подписаться на папку ➡️ Подтвердить участие в боте Итоги — 19 июня.

21 мая сходил в ArtPlay на митап ИИ-разработчиков от PWD и Indexis. По ощущениям, рынок уже прошел стадию “смотрите, ИИ может написать код”. Теперь разговор постепенно смещается в другую сторону: кто будет отвечать за результат, поддержку, продажи и экономику таких проектов. Один из главных инсайтов для меня — бизнес всё чаще спрашивает, должна ли разработка с ИИ стоить дешевле. И это не абстрактный вопрос из зала. Мы уже слышим его от клиентов. Логика понятная: если ИИ ускоряет работу, значит должно быть дешевле, правда? Но тут есть нюанс. Код написать быстрее — это только часть истории. Дальше этот код нужно поддерживать, развивать, проверять, документировать, чинить, обновлять и объяснять, почему оно вообще так работает. И вот тут появляется главный вопрос: кто берет на себя риски вайбкодинг-проектов? Потому что бизнесу не нужен просто “быстро собранный проект”. Ему нужен продукт со всем вытекающим: поддержкой, ответственностью, понятной логикой развития и нормальной экономикой. У Андрея Иванова как раз был доклад про Agent-First агентство: как запускать проекты без раздутого штата. Мне эта формулировка понравилась. Не “давайте заменим всех на ИИ”, а скорее “давайте перестроим процесс так, чтобы агентство могло делать больше без бесконечного раздувания команды”. Причем с Андреем мы часто пересекаемся в Питере и много обсуждаем эту тему вживую, так что было интересно увидеть продолжение разговора уже на сцене в Москве. Еще из важного — как вообще продавать ИИ бизнесу. И тут, кажется, плохая идея продавать “ИИ” как технологию. Клиенту не нужен сам факт, что где-то внутри GPT, агенты или новая модная обертка. Ему нужен понятный результат: быстрее обработали заявки, сократили ручную работу, ускорили подготовку КП, снизили риски, навели порядок в процессе. В презентации Мостяева хорошо прозвучала мысль про value-based подход. Если команда с ИИ делает быстрее, то продажа часов начинает выглядеть странно. Клиент спрашивает: “почему стоит столько же, если вы делаете быстрее?” И это нормальный вопрос. Похоже, агентствам придется учиться продавать не часы, а результат. Отдельно интересно было послушать Вадима Митякина, который вел круглый стол. Он развивал мысль из своего недавнего поста про экспертные фирмы в эпоху ИИ: агентствам пора продавать не часы и не “людей в проект”, а экспертизу, продуктовый подход и ответственность за результат. В итоге митап получился не про “сейчас ИИ всё сделает за нас”, а про более практичную вещь: как агентствам зарабатывать и отвечать за результат, когда ИИ уже внутри процесса. ИИ действительно ускоряет работу. Но вместе со скоростью появляются новые вопросы: как продавать такие проекты, кто отвечает за качество, кто поддерживает результат, как считать стоимость и как доводить быстро собранную штуку до нормального продукта. Похоже, главный навык ближайшего времени — не просто уметь собирать проекты с ИИ, а уметь превращать их в продукт, который бизнесу понятно как купить, использовать и развивать. #AI #vibecoding #разработка