Цифра Комягина

Конечно, за две недели воспроизвести всю Miro с их 100 млн пользователей, безопасностью, отказоустойчивостью, 250 интеграциями и пятнадцатью годами продуктовой разработки невозможно. Но большинству компаний и не нужна «вся Miro». Чаще всего нужны несколько конкретных процессов: провести стратегическую сессию, нарисовать архитектуру, собрать CJM, вести продуктовый roadmap и совместно поработать над схемой.

Еще недавно ради этого покупали несколько сотен лицензий. Теперь технический директор вполне может хотя бы посчитать второй вариант. Для SaaS с оплатой за каждое рабочее место это новая и довольно неприятная математика.

А сколько получили основатели?
Признаюсь — этот вопрос стал основным драйвером этого расследования. Miro привлекла почти полмиллиарда долларов. Венчурные инвесторы обычно имеют ликвидационные привилегии — право при продаже забрать свои деньги раньше владельцев обычных акций. Я решил, что после продажи за $1,79 млрд инвесторы съедят почти весь пирог, а Хусид с Шардиным после пятнадцати лет работы получат “околоноля”.

Давайте разбираться.

Самый интересный раунд здесь последний. В 2022 году инвесторы вложили $400 млн по цене $35,92 за акцию и получили стандартную привилегию. Их доля при оценке $17,5 млрд составляла всего около 2,3%.

Если сейчас они просто конвертируют акции в обычные и получают свою долю от $1,79 млрд, им достанется примерно $41 млн. Поэтому они, разумеется, воспользуются этим пунктом и заберут вложенные $400 млн.

После этого останется еще примерно $1,39 млрд.

Более ранним инвесторам уже выгодно поступить наоборот. Series B покупала акции по $1,68, Series A — по $0,36, самые ранние раунды — примерно по два-три цента. По моей приблизительной модели после выплаты Series C на остальные акции остается около $2,9 за штуку.
То есть ранние инвесторы на продаже Miro вполне неплохо заработают.

Сколько достанется самим Хусиду и Шардину, посчитать достоверно пока невозможно. Их актуальных долей в открытых источниках нет. Ну, или по крайней мере я не нашел таких данных. Можно только предположить. Если у двух основателей к моменту сделки осталось, например, 10% компании, это примерно $140 млн на двоих. Если 20% — около $280 млн. Если 30% — больше $400 млн. И то — до налогов.

Итак, версия про то, что инвесторы забрали все, а два пермяка вышли из пятнадцатилетней истории с пустыми карманами, признается нежизнеспособной. Как минимум, несколько десятков миллионов долларов парни заработали.

А стоило ли вообще продавать?
Вот на этот вопрос у меня пока нет хорошего ответа.

Miro прибыльна. Денег на счетах — вагон и маленькая тележка. Срочно спасать компанию не требуется. Более того, Хусид пишет, что с предложением пришла сама Bending Spoons.

В своем письме сотрудникам Андрей перечисляет три критерия, которыми руководствовались при выборе покупателя: будущее пользователей, будущее команды и «лучший результат для инвесторов». Это все стандартные для IR слова.

Вот только некоторые из инвесторов сидят в Miro уже восемь лет. И это может быть важным.

Может быть, совет директоров решил, что ждать возвращения к прежней оценке бессмысленно. Возможно, рост уже недостаточен для IPO. А может быть и впрямь, будущая конкуренция в мире, где стоимость разработки ПО продолжает падать, выглядит слишком неприятно.

Отдельного поста заслуживает сама Bending Spoons. За неделю до объявления сделки с Miro они закончили покупку Airtable. До этого собрали Evernote, WeTransfer, Vimeo, AOL и целую коллекцию других известных продуктов. Очень интересные ребята. И очень своеобразная бизнес-модель. Но про них я напишу уже в другом посте. Потому, что этот и без того огромным получился.

Цифра Комягина

На рынке случилось уMIROтворение
10 сентября Miro подписала соглашение о продаже итальянской Bending Spoons. Сделка еще не состоялась: ее должны одобрить регуляторы, на и оформить ее еще нужно — так что все случится скорее всего уже в 2027 году. Но факт остается фактом.

Сумма сделки — $1,355 млрд. У Miro на счетах еще примерно $435 млн чистыми, поэтому общая сумма, которая достанется акционерам, составит около $1,79 млрд. При этом, в последнем раунде, в январе 2022-го, инвесторы оценили Miro в $17,5 млрд.

Выручка от постоянных платежей компании (ARR) сейчас около $600 млн, причем почти 90% выручки приходит от бизнеса и крупных корпоративных клиентов. Платной версией пользуются почти 4 млн человек, Miro встроена в процессы 250 тысяч организаций, а 750 клиентов платят ей больше $100 тысяч в год каждый. Основатель (Андрей Хусид) пишет, что компания прибыльна.

То есть Bending Spoons собирается заплатить за работающий прибыльный бизнес примерно 2,3 его годовых регулярных выручки. Это дешево даже по сильно похудевшим меркам сегодняшнего SaaS-рынка: медиана частных сделок сейчас около x4 выручки.

Мне стало интересно разобраться, что случилось с Miro. Потому что компания точно не выглядит умирающей, а сделка выглядит едва ли не вынужденной.

Как все начиналось
Miro начали делать в Перми в 2011 году Андрей Хусид и Олег Шардин. Тогда компания называлась RealtimeBoard, а продукт был, по сути, бесконечной онлайн-доской для совместной работы.

Дальше ребята поймали совершенно фантастическую волну.

В апреле 2020 у Miro было 5 млн пользователей и 20 тысяч платящих компаний. Через двадцать месяцев — уже 30 млн пользователей и 130 тысяч компаний.

Ковид запер половину офисного мира по домам, и внезапно выяснилось, что доска с маркерами в переговорке тоже нуждается в цифровом аналоге.

В январе 2022 года Miro привлекла $400 млн. Компания уже тогда была прибыльной, работала с 99% Fortune 100, а инвесторы оценили ее в $17,5 млрд. Это около x60 ARR. Даже по безумным меркам венчурного рынка 2021 года — очень дорого.

А потом … что-то случилось. В 2023 году Miro сократила 119 человек, или 7% штата. В 2024-м — еще 275, уже 18%.

Причем к 2024 году ARR переваливает уже за $500 млн. Сейчас она порядка $600 млн. То есть как-будто компания продолжает расти. Просто совсем не с той скоростью, которой от нее ожидали инвесторы в 2022 году.

При чем тут SaaSпокалипсис
В июне я опубликовал большой пост про то, что происходит с рынком SaaS.

Многим хотелось бы привязать падение оценки Miro исключительно к ИИ и вайбкодингу. Но это было бы очень грубым обобщением. Основная переоценка SaaS началась раньше, вместе с окончанием эпохи бесплатных денег и ковидного безумия.

Покупатель платит не за прошлое. Он покупает будущий денежный поток. И вот на него агентная разработка действительно уже начинает влиять.

Miro живет в классической для SaaS модели оплаты за пользователей: например, тариф Business сейчас стоит $20 за человека в месяц. Пятьсот сотрудников — уже $120 тысяч в год. Пять тысяч — $1,2 млн. О-кей, пусть даже для enterprise будут какие-то негласные и ощутимые скидки за объем. Ну, допустим, 50%. Но все равно — это сотни тысяч долларов ежегодно.

Раньше выбор часто выглядел просто: купить готовый продукт или потратить несколько лет и, зачастую, не один миллион долларов и построить собственный.

Цена второго варианта сейчас стремительно падает. Причем я наблюдаю это уже воочию. Мы в SVK.Digital сейчас работаем с крупной сетью клиник над заменой одной из ключевых информационных систем. За существующее решение заказчик ежегодно платит десятки миллионов рублей. Еще несколько лет назад предложение «давайте напишем свою МИС» я бы сперва очень тщательно проверял на здравый смысл. Сегодня мы действительно рассматриваем этот вариант и считаем его экономику.

С Miro происходит примерно та же угроза, только в гораздо более простом классе ПО.

ROI от внедрения ИИ

Вопрос “внедрять или не внедрять” больше не стоит на повестке дня. Этот поезд уже ушел. Вопрос только в одном — рискнете ли вы сейчас для того, чтобы получить возможность рвануть вперед уже несколько месяцев или будете тем самым скупым, который в следующем году вынужден будет заплатить дважды за то, чтобы ликвидировать отставание от конкурентов.

Совсем недавно я писал здесь про сериал «Стеклянный дом». Семейная стекольная фабрика, середина 90-х. В одной из серий сын убеждает отца начать компьютеризацию производства. Аргумент сына: если мы этого не сделаем, конкуренты нас обгонят. Ответ отца: эта технология никогда не окупится.

Я сейчас ровно этот эпизод наблюдаю в реальной жизни.

К нам в SVK.Digital ежемесячно приходят десятки запросов на внедрение ИИ. Мы вместе с заказчиком разбираем процессы, придумываем решение, считаем сроки и стоимость. А через несколько дней возвращается грустный заказчик: "Руководство просит посчитать экономический эффект".

Вообще-то это нормальное требование. И посчитать экономический эффект можно. Дайте исходные цифры.

Только вот их обычно нет нифига. Стоимость лида компании знают. Стоимость клика знают. Стоимость найма сотрудника иногда тоже знают. А сколько стоит одно обращение в юридический отдел? Сколько стоит поиск документа в корпоративной базе? Сколько часов дорогих специалистов уходит на перекладывание данных из одной таблички в другую?
Никто никогда не считал. Значит, сначала придётся измерить процесс «до», а уже потом считать эффект от его изменения. Не умеете — приходите к нам, поможем. Тут как раз никакой магии нет.

Но есть проблема посложнее.

Мы прямо сейчас заканчиваем проект для финансового директора крупного фармацевтического холдинга. Каждый месяц компания обязана готовить огромный отчёт для регулятора: примерно 700 строк на 50 колонок — 35 тысяч ячеек. На его подготовку финансовый директор тратит два полных рабочих дня. Каждый месяц. Тупо собирает данные из разных источников, сводит, проверяет и перекладывает из одной таблицы в другую.

Мы автоматизировали этот процесс. Теперь отчёт собирается примерно за семь минут.

Давайте считать экономический эффект?

Допустим, оклад финдиректора — 600 тысяч рублей. С налогами, взносами и остальными расходами компании этот человек обходится грубо в миллион в месяц. Два рабочих дня — около 10% рабочего времени. Получается, мы «сэкономили» компании 100 тысяч в месяц, или 1,2 миллиона рублей в год?

А давайте компнем глубже ...

Финдиректор как получал свою зарплату, так и продолжит получать. Компания просто вернула себе примерно 24 рабочих дня в год очень дорогого специалиста. Но возможно, теперь эти 24 дня он потратит на управление денежными потоками, переговоры с банками, снижение издержек или поиск денег для нового производства. Сколько это стоит?

А то, что отчёт теперь гарантированно собирается вовремя? А снижение риска человеческой ошибки в 35 тысячах ячеек обязательной отчётности? А снижение регуляторного риска для фармацевтического производства? Это тоже экономический эффект. Только хрен вы посчитаете его до рубля.

Можно строить модели, закладывать вероятности, считать пессимистичный и оптимистичный сценарии. И это нужно делать. Но в инновациях не бывает гарантий.

Пока одна компания шестой месяц пытается рассчитать срок окупаемости ИИ с точностью до второго знака после запятой, другая запускает десять пилотов. Семь из них провалятся. Два окажутся так себе. Один радикально изменит какой-нибудь бизнес-процесс.

И через полгода первая компания всё ещё будет согласовывать экономическое обоснование. А вторая станет быстрее, эффективнее и ... скорее всего заберет клиентов первой.

Поэтому если денег на инновации сейчас действительно нет — так и скажите. Времена лютые, все всё поймут.

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

Вы не ROI считаете. Вы ищете повод ничего не менять.

Для текстов на русском я больше не использую Claude

OpenAI генерирует коммерческие тексты на русском лучше Claude. По крайней мере, в моих задачах. Это знание обошлось мне примерно в десять часов жизни.

Уже около полугода коммерческие предложения для большинства запросов в SVK.Digital мы собираем с помощью собственной мультиагентной платформы. Люди, разумеется, всё читают, проверяют и правят, но большую часть черновой работы делают агенты.

До недавнего времени за тексты у нас отвечал Claude. И меня все устраивало.

Но на выходных попался сложный кейс. И тут я обнаружил, что Claude пишет какую-то совершенно механизированную нейрохуету: каждый абзац вроде бы грамматически правильный, мысли на месте, факты не потеряны — а читать невозможно.

Я решил, что проблема в настройках и потратил целый день, переписывая инструкции для агентской роли Редактора. Добавлял ограничения, убирал ограничения, кормил ему примеры хороших текстов, объяснял структуру, стиль, драматургию.

Становилось то чуть лучше, то чуть хуже. Но хорошего текста все равно не выходило.

Тогда я предположил, что сам загнал модель в угол противоречивыми инструкциями, и практически обнулил системный промпт.

Стало лучше. Исчезла часть нейрослопа, отдельные абзацы начали читаться нормально. Но текст всё равно не складывался в историю. Не было ритма, переходов, драматургии. Получалась пачка более-менее приличных абзацев, случайно оказавшихся рядом.

К этому моменту я уже начал натурально беситься. Взял очередной «шедевр» Claude, скопировал его в ChatGPT, двумя абзацами объяснил задачу и написал: «Сделай из этого нормальный текст». И ... получил практически готовый вариант с первого раза.

Озадаченный, решил проверить, не случайность ли это. Перестроил платформу так, чтобы роль Редактора работала на модели OpenAI. И примерно пятнадцать страниц коммерческого предложения, которые я безуспешно мучил предыдущие десять часов с Claude, собрал примерно за час.

Рассказал об этом товарищу из другого проекта. Он как раз все выходные воевал с похожей задачей. Переключился на OpenAI — та же история: за час получил результат, который до этого никак не складывался.

Выборка, конечно, пока смешная — два проекта и два раздражённых человека. Но для себя решение я уже принял.

Если задача — написать хороший коммерческий текст на русском: предложение, лендинг, рекламный материал, продажную презентацию — первым делом я сейчас иду в модели OpenAI.

Claude я по-прежнему очень люблю и использую в качестве основного инструмента для большинства своих задач. Но именно в связном русском повествовании OpenAI сейчас у меня выигрывает с неприличным отрывом.

В следующем посте поделюсь ключевыми принципами для написания ИИ-редактора. В этот уже не поместилось.

Не всё в жизни нужно делать ради результата.

За последние три дня я дважды столкнулся с этой мыслью.

Несколько дней назад завтракал со своим хорошим другом. Ему чуть за сорок.

В детстве он занимался лыжами. Смотрел на фотографии именитых спортсменов, увешанных медалями, и мечтал когда-нибудь оказаться среди них.

Потом институт, работа, бизнес, семья — в общем, обычная взрослая жизнь. Лыжи остались хобби выходного дня, а олимпийская мечта отправилась на ту же дальнюю полку, куда большинство из нас складывает детские планы.

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

И начал пробовать.

Сейчас он тренируется с профессиональными тренерами, проводит по две тренировки в день, следит за питанием, ездит на сборы и соревнования.

А самое интересное — он уже отобрался на следующий чемпионат мира по лыжным гонкам. Тот самый, где выступают сильнейшие лыжники планеты.

И совершенно серьёзно собирается идти дальше — пробовать отобраться на Олимпийские игры.

Получится или нет — другой вопрос. Взойти на олимпийский пьедестал после сорока, мягко говоря, непросто.

Но многие ли из нас вообще могут сказать: «В сорок с лишним я отобрался на чемпионат мира»?

Меня, если честно, больше всего впечатлил даже не сам план, а количество усилий, которые взрослый занятой человек готов в него вкладывать.

Поэтому я спросил его: а что будет, если чемпионат в итоге сорвётся? Травма. Какие-нибудь формальные проблемы. Что угодно — за несколько месяцев до старта.

И вот его ответ меня действительно зацепил.

Он сказал: ничего страшного.

Потому что за это время он познакомился с огромным количеством интересных людей. Побывал в местах, куда иначе никогда бы не попал. Получил новый опыт. Привёл себя в отличную физическую форму. И теперь ему, в конце концов, просто нравится смотреть на себя в зеркало.

Получится чемпионат — прекрасно.

Не получится — всё это никуда не денется.

На следующий день я открыл канал другого предпринимателя. Тоже очень успешного, многого добившегося. Последние его посты были совсем о другом — о панических атаках и о том, каким правильным решением для него в какой-то момент стало начать принимать антидепрессанты.

Я не знаю причин его состояния и не собираюсь их додумывать.

Но две эти истории почему-то сложились у меня в одну картинку.

Потому что сам я гораздо больше похож на второго предпринимателя.

Я привык относиться к жизни примерно так же, как к бизнесу. Должна быть цель. План. Дедлайн. Измеримый результат.

Добился — хорошо.

Не добился — значит, потратил время зря.

Для бизнеса это, наверное, неплохая система координат. А вот всю остальную жизнь я зачем-то много лет пытался запихнуть в тот же Excel.

И разговор с моим другом заставил меня впервые всерьёз задуматься: а обязательно ли цель вообще должна быть достигнута?

Если по дороге к ней ты стал здоровее, познакомился с замечательными людьми, увидел новые места, научился чему-то новому и несколько лет просыпался утром с интересом — трудно назвать это поражением.

Семь принципов, которые улучшат ваш вайбкод

1. Декомпозиция рулит. Тут все как с людьми: не стоит давать ИИ сложных задач одним промптом. У каждой задачи на входе должны быть полноценно описанные исходные условия и желаемый результат. Если задача настолько большая, что описание выходит слишком объемным, эффективнее будет разбить её на серию небольших задач и делать последовательно, шаг за шагом.

2. Контекстом памяти нужно управлять. В целом, базовые инструменты управления встроены в движок самих моделей, но полагаться на них полностью и неделями работать в рамках одной сессии неэффективно и очень дорого. Научитесь делать точки восстановления контекста, чекпоинты и качественную связанную документацию. Очищайте сессию каждый час-полтора.

3. Не пользуйтесь ИИ там, где нужен воспроизводимый результат. С расчетом сложных формул или заполнением документа по заданному шаблону лучше справится старый добрый детерминированный код. Где не нужны рассуждения, там не нужна языковая модель и reasoning.

4. Не теряйте контроль над кодом. Я не говорю о том, что нужно дотошно вычитывать каждую строчку кода. Но, как минимум, вы должны понимать архитектуру того, что написали — то, как код работает и почему работает именно так. Если вы потеряли контроль над кодом, самый простой способ его восстановить — удалить непонятный фрагмент и переписать с нуля, уже тщательно контролируя каждый шаг.

5. Ограничивайте модель там, где вам требуется соблюдение определенных правил и процедур. Дизайн-системы, стили кодирования, правила декомпозиции задач, Tone Of Voice ваших документов — для ключевых регламентированных процессов должны быть созданы письменные инструкции для ИИ.

6. Не пренебрегайте практикой ревью (аудита) кода. Правило вытекает из предыдущего. По своей природе LLM могут терять куски контекста и понемногу от них отступать (дрифтить). Поэтому автоматизируйте процедуру периодического аудита уже написанного на соответствие заданным правилам. Время от времени стоит проводить “ручное” ревью. В Amazon, к примеру, после серии крупных инцидентов в прошлом году, завели правило ручного code-review перед раскаткой кода на боевые сервера.

7. Не работайте в одиночку. Самое, пожалуй, сложное правило. Но большие проекты по-прежнему не делаются в одиночку. Ключевых причины две. Первая — человек теперь главное ограничение ИИ-систем. Именно он должен успевать осознавать то, что создает, а еще человек может уставать, терять энергию, выгорать. Во-вторых, не бывает универсальных экспертов и человек, который очень хорош в коде, может быть не так хорош в дизайне или текстах. Отчасти проблема решается созданием агентов с нужной экспертизой, но если такой агент создан и обучен человеком с низкой квалификацией в предметной области, то результаты его работы будут соответствующими.

Какие специалисты больше не нужны в командах разработки?

Поспорил вчера с коллегами по цеху о том, как должны выглядеть современные команды разработки.

Еще недавно в заказной разработке мы собирали ее примерно так: руководитель (продукта/проекта), аналитик, UX/UI-дизайнер, frontend- и backend-разработчик, QA. При необходимости добавляли архитектора, DevOps-инженера, специалиста по машинному обучению и других редких зверей.

С появлением ИИ-агентов этот состав не исчез. Но содержание почти каждой роли уже меняется.

Руководитель

Пока необходим. Ответственность на ИИ не переложишь.

Более того, когда команда способна производить решения быстрее, цена неправильного решения возрастает. Кто-то по-прежнему должен разговаривать с заказчиком, удерживать цель проекта, разрешать противоречия и отвечать за результат.

Аналитик

Эта роль не исчезает, а поднимается на уровень выше.

В подходе Spec-Driven Development спецификация становится главным источником истины для людей и агентов. Черновики документов, диаграммы, пользовательские истории и критерии приёмки теперь действительно могут писать роботы.

Но кто-то должен понять, какую проблему решает заказчик, выявить противоречия, определить границы системы и заметить требования, о которых никто не догадался спросить.

Я называю такого специалиста архитектором спецификаций.

Многие коллеги уверены, что аналитиков ИИ заменит первыми: мол, что это за программист, который не способен разобраться в том, что собирается программировать?

Способных — много. Способных качественно выявить, структурировать и согласовать требования — единицы. Поэтому сильный аналитик становится не менее, а более ценным членом команды.

Дизайнер

Качественный UX/UI-дизайн всё ещё отличает классный продукт от просто работающего.

Мы только что выиграли сложный тендер во многом благодаря опытному дизайнеру. Claude Design, который явно использовала конкурирующая команда, предложил неплохие варианты, но цельной концепции уровня живого специалиста не создал.

При этом значительная часть прежней работы дизайнера действительно автоматизируется. Агенты могут собирать интерфейсы на основе существующей дизайн-системы. Роль дизайнера теперь — коммуникация с заказчиком, креатив, ключевая концепция, основные элементы дизайн системы и авторский надзор за работой агентов дизайна.

Разработчик

Здесь изменения заметнее всего.

Деление на фронтенд- и бэкенд-разработчиков пока никуда не исчезло, но постепенно становится вторичным. Современный инженер должен уметь отвечать за целый модуль: интерфейс, серверную логику, данные, интеграции, тесты, безопасность и наблюдаемость.

Это не означает, что все внезапно стали одинаковыми универсалами. Один инженер по-прежнему глубже понимает браузер и интерфейсы, другой — базы данных и серверную часть.

Но оба должны уметь поставить задачу агентам, организовать сборку решения, проверить результат и отвечать не за свою половину кода, а за работающий модуль целиком.

QA

Мне казалось, что качественные спецификации, TDD и хорошее автоматическое покрытие позволят почти полностью убрать ручное тестирование. Но опытные товарищи со мной не согласились.

Тесты проверяют только то, что команда догадалась в них заложить. Они не гарантируют, что мы правильно поняли пользователя, предусмотрели странный сценарий или вообще построили удобный продукт.

Поэтому QA тоже не исчезает. Он превращается из человека, который вручную прокликивает написанные кем-то тест-кейсы, в инженера по качеству: проектирует стратегию проверки, ищет системные риски, проверяет граничные сценарии и контролирует работу тестирующих агентов.

Наш опыт

За первый год интенсивного использования ИИ-агентов состав наших команд сократился умеренно. Там, где раньше требовалось пять-семь человек, иногда хватает трех-пяти. Но до команд из одного человека, управляющего армией роботов, мы пока не дошли.

Главное изменение не количественное, а качественное.

Профессии не исчезают. Исчезает право специалиста оставаться узким исполнителем.

В новой команде ценится не тот, кто быстрее производит документы, макеты, код или тест-кейсы. Ценится тот, кто способен поставить задачу, принять решение, организовать работу агентов и лично ответить за результат.

Мы прекратили найм сотрудников, не владеющих ИИ

Надеюсь, вы тоже.

Да, эффективность от использования ИИ-инструментов до сих пор не измерена и часто преувеличивается. Но революция случилась, ИИ стал привычным рабочим инструментом. Таким же, как в свое время, владение Word и Excel.

В итоге, нам пришлось сформулировать, что именно мы считаем владением ИИ и как это проверять.

На июль 2026 года наша шкала выглядит так.

Начальный уровень.
Использует ChatGPT, Claude, Gemini, Perplexity или другие модели для поиска информации, подготовки черновиков, анализа текстов и решения повседневных рабочих задач. Понимает, что ответ модели нужно проверять.

Базовый уровень.
Умеет не только общаться с моделью в чате, но и получать законченный результат в виде файла: документ, таблицу, презентацию или изображение.

Продвинутый уровень.
Настраивает ИИ под собственные задачи: создаёт инструкции, проекты, навыки. Не начинает каждый диалог с объяснения модели, кто он и чем занимается.

Вайбкодинг.
Умеет развернуть среду разработки, подключить ИИ-инструменты и собрать несложный рабочий продукт: сайт, чат-бот, внутренний сервис или аналитический дашборд.

Автоматизация.
Умеет связать модели с корпоративными системами через API или n8n. Использует мультиагентный подход для автоматизации полноценных бизнес-процессов. Понимает, где нужен ИИ, а где достаточно обычного алгоритма.

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

Разумеется, требуемый уровень зависит от должности. От бухгалтера, менеджера проекта и разработчика мы ждём разных навыков. Но нулевой уровень больше не принимаем ни для одной позиции, предполагающей интеллектуальную работу.

Проверяем навык так же, как проверяли владение Excel или средой разработки: даём конкретную задачу и просим выполнить её в реальном времени с демонстрацией экрана.

Здесь есть важное ограничение: проверяющий должен владеть инструментом не хуже кандидата. Иначе собеседование быстро превращается в проверку того, насколько хорошо кандидат умеет изображать бурную деятельность.

Покажите этот пост своему HR и перестаньте нанимать людей, которые демонстративно игнорируют главный рабочий инструмент этого года.

Цифра Комягина

Главный критерий выбора подрядчика по заказной разработке — прикрыть задницу. В смысле, когда заказчик выбирает подрядчика из ТОП-5, он часто покупает не качество разработки, а страховку на случай провала.

Это старая корпоративная магия: "Nobody ever got fired for buying IBM".

Если всё пошло хорошо — молодец. Если всё пошло плохо — ну а что ты ещё мог сделать? Это ж IBM.

В России есть Рейтинг Рунета, Тэглайн, отраслевые премии, дипломы, красивые места в таблицах, логотипы крупных клиентов на главной странице. Чем больше всего этого — тем сильнее "ну а что ты ещё мог сделать?" в случае чего.

Один из наших клиентов за 5 лет сменил ТРИ топовые команды на проекте. Каждая обошлась недешево. Каждой дали поработать, но проект не закончился. В этом году обещают "точно закончить".

Место в рейтинге почти ничего не говорит о том, кто именно будет делать ваш проект. Оно может говорить о выручке, размере компании, PR-бюджете, количестве заявок на конкурсы, умении красиво упаковывать кейсы и вовремя ездить по отраслевым тусовкам.

Но оно не отвечает на главный вопрос: какой конкретно человек сядет за клавиатуру и будет писать код в вашем проекте.

На пресейле вам покажут лучших людей. Харизматичный ведущий архитектор нарисует схему, техдир уверенно расскажет про нагрузку и безопасность, аккаунт красиво разложит этапы проекта, в презентации всё будет выглядеть так, будто завтра к вам высаживается инженерный спецназ.

А потом вы подписываете договор.

И спецназ уезжает на следующий пресейл!

В продакшне вообще другая жизнь. Продажи и производство в больших галерах часто существуют как две параллельные вселенные. Одни люди обещают, другие делают, третьи управляют ожиданиями, четвёртые потом объясняют, почему "по результатам уточнения требований необходимо актуализировать сроки".

А как только проект начнёт гореть, надо будет выбрать, что резать. Аналитику, тестирование, архитектуру, качество кода, состав команды, сроки или собственную маржу. Угадайте, что режут последним.

Главный вопрос подрядчику должен звучать не "какое у вас место в рейтинге?". И даже не "сколько у вас сотрудников?". Главный вопрос — "Покажите мне тех, кто будет делать мой проект в первый месяц". Кто тимлид? Кто аналитик? Кто пишет код? Кто принимает архитектурные решения? Кто отвечает за качество? Сколько времени эти люди реально будут выделены на проект? Что произойдёт, если одного из них снимут или он уволится? Кто и как примет решение о замене?

А второй вопрос — "Расскажите, какой проект эта команда уже завалила и что вы после этого изменили".

Не компания в целом, а именно эта команда.

Потому что красивые кейсы есть у всех. Дипломы есть у всех. Слайды про процессы есть у всех. А вот честно говорить о провалах умеют только те, кто действительно научился на них работать. Это примерно как с хиругами: если с вами говорят о рисках операции, то, вероятно, хирурга они волнуют. Если продают — вероятно, его волнуют продажи.

История получила интересное развитие. Anthropic анонсировала, что начиная с 8 июля пользователей платных тарифов могут попросить подтвердить личность, предоставив скан паспорта и селфи с этим самым паспортом. Речь идет о тарифах Free, Pro и Max. Корпоративные тарифы и пользователей API-платформы это затронуть не должно.

Мотивы понятны — Anthropic хочет вернуть доступ к своей новейшей модели хотя бы для американского рынка.

Воспользуются ли авторы Claude ситуацией и не начнут ли массово банить пользователей с российскими паспортами? Риск ненулевой: Anthropic уже использует региональные ограничения и прямо пишут, что после проверки аккаунт может быть заблокирован за использование сервиса из неподдерживаемых регионов.

Компания может решить не тратить усилия на то, чтобы разбираться, кто перед ней — житель России или человек, давно переехавший в Сербию или Нидерланды, но сохранивший только российский паспорт.

Наверняка мы знать не можем. Поэтому остается подождать две-три недели и уже по факту узнать, какими будут действия Anthropic.

Но тем, кто уже не представляет своей повседневной работы без агентного кодинга, стоит подготовиться к возможным негативным сценариям.

Какие я вижу реальные альтернативы?

1️⃣ Codex от OpenAI. Эта компания исторически более лояльно относится к российским пользователям и многие считают, что последние версии модели даже сильнее Opus 4.8 от Claude Code.

2️⃣ Cursor, о покупке которого буквально вчера объявила компания Илона Маска. Тут всё не так однозначно, но многие программисты с многолетним опытом заявляют, что имеющегося Composer 2.5 им хватает “с головой” для решения своих профессиональных задач. Менее опытным разработчикам с продуктом может быть не так комфортно, как с Claude Code или Codex, хотя обе эти (и другие) модели присутствуют в Cursor в том числе.

3️⃣ OpenRouter — единая платформа, объединяющая в себе сотни больших языковых моделей (LLM) от разных разработчиков. В ней, в том числе, тоже есть ведущие модели, а сам OpenRouter заявил, что комбинация ведущих моделей DeepSeek, Kimi и Gemini в составе модели Fusion уступает сегодняшнему флагману-изгою Fable 5 меньше, чем на 1%.

4️⃣ Китайские модели — уже упомянутый DeepSeek, Kimi, и выскочивший, как черт из табакерки Z Ai с моделью GLM 5.2.

Если история чему-то и учит, так это тому, что строить рабочие процессы вокруг одной-единственной модели становится все опаснее. Сегодня проблемы у Claude, завтра — у OpenAI или Google. Поэтому главный навык ближайших лет — не привязанность к конкретному инструменту, а умение быстро переключаться между ними.

Ну и не унывайте — в крайнем случае перейдем на отечественный Гигачат, хотя с учетом современных реалий, нет никаких гарантий того, что и он, спустя какое-то время, не станет предоставляться только по паспорту ))

Штрафы за авторизацию через Google/Apple

Вчера по ведущим СМИ прокатилась волна публикаций, о том, что Госдума приняла сразу в двух чтениях закон, по которому теперь владельцев сайтов будут штрафовать на 700к за авторизацию через зарубежные сервисы.

Давайте вместе разбираться, что случилось и нужно ли нам с вами что-то предпринимать в этой связи?

Что случилось?
Во-первых, требование авторизовывать российских пользователей только определенными способами действует аж с 1 декабря 2023 года — это поправки в 149-ФЗ «Об информации». До сих пор не было административной ответственности за нарушение этого требования. Вчера, 9 июня, Госдума приняла в третьем чтении именно поправки в КоАП — то есть ввела штрафы за то, что и так уже три года было незаконно.

Это вообще меня касается?
Если у вас на сайте нет авторизации — то есть это простой лендинг или информационный сайт, без функционала, закрытого регистрацией/авторизацией — дальше можете не читать.

А вот если в какой-то момент на вашем сайте, портале, интернет-магазине, в вашем мобильном приложении возникает окошко регистрации пользователя, без которой невозможен доступ к части функционала (например, доступ в личный кабинет или оформление заказа), то эти поправки касаются вас самым непосредственным образом.

За что будут штрафовать?
Нет, вопреки разлетевшемуся вчера мнению, штрафовать будут НЕ пользователей, которые авторизуются с помощью учеток Google или Apple, а владельцев сайтов, которые такую авторизацию допускают для российских пользователей.

Запрещена только сама авторизация (OAuth-вход) через иностранный сервис. Закон обязывает обеспечивать аутентификацию граждан РФ через один из четырех описанных способов:

— номер мобильного телефона;
— ЕСИА (Госуслуги);
— ЕБС (биометрию);
— либо сервис авторизации, владелец которого — гражданин России без иного гражданства или российское юрлицо (например, Яндекс.ID, VK, Сбер, и т.д.).

Использовать сам адрес @gmail.com как логин/идентификатор при регистрации — можно, это не запрещено.

Чем грозит нарушение?
Для физических лиц предусмотрена ответственность до 20к рублей, для юридических лиц — до 700к.

На момент написания этого поста, поправки еще должны пройти оставшиеся этапы законодательной процедуры: одобрение Советом Федерации, подпись президента и официальную публикацию перед тем, как по ним можно будет начать штрафовать. Однако рассчитывать на то, что проблему можно отложить на потом, я бы не рекомендовал.

Ладно, что делать-то?
Разумным выглядит примерно такой план действий:

1. Провести аудит, выявить, в каких ваших системах и сервисах используются зарубежные сервисы авторизации пользователей. Тут важно понимать, что речь идет не только о Google и Apple, но и о других распространенных службах (Firebase, Auth0, и т.д.)

2. Отключить возможность авторизации через таких сервисы для новых пользователей.

3. Добавить (если еще не было) один из разрешенных способов авторизации.

4. Легализовать ранее зарегистрировавшихся через Google/Apple пользователей. Это ключевой и недешёвый пункт. Раньше запрет де-факто касался новых регистраций; теперь его распространяют и на ранее зарегистрированных. При следующем входе пользователя, привязанного к Google/Apple, придется заставить привязать телефон или российский метод.

5. Сделать рассылку текущим пользователям с просьбой уточнить регистрационные данные и установленным дедлайном для этой процедуры.

6. По истечение дедлайна — деактивировать тех пользователей, кто не перешел на новые способы авторизации и окончательно удалить из сервиса возможность авторизации через зарубежные сервисы.

Если вы не уверены, затрагивает ли новый закон ваш сайт или приложение, мы можем провести технический аудит и подготовить план миграции: проверим риски, оценим объем работ и при необходимости переведем проект на новые способы авторизации без потери пользователей и данных. Пишите мне в личку.

Цифра Комягина