Директорат Surf обсуждает

🥐 Сделали дизайн-концепт для крупной сети пекарен-кофеен Петербурга. Мы хотели, чтобы приложение ощущалось как сам город, поэтому цвета взяли прямо с колерной карты фасадов. А вместо привычной системы «баллы = рубли» придумали секретное меню, которое открывается только за бонусы. ⬆️ Больше фичей показали в видео и на сайте: моментальный заказ, атмосфера любимых улиц и персональные акции, которые не заваливают тебя пушами. 🏄‍♂️ Подробнее на сайте

Сделал CLI-утилиту, которая уже круто показала себя в проектах, называется katana. Проблема многих проектов — крупные файлы на несколько тысяч строк. Они мешают агентам: их долго читать, и забивается контекст. А агенту тяжело их разрезать — нужно долго читать, а потом долго писать куски нарезки, и т.к. это проходит через LLM, привносится недетерминированность. katana позволяет агенту архитектурно красиво разбивать файл без его чтения и записи. CLI даёт агенту сигнатуры всего содержимого файла, это работает через AST. Агент проектирует красивое разбиение, возвращает katana JSON с проектом разбиения, katana детерминированно разрезает файл, импорты фиксятся линтером. Профит. Т.е. агенту не пришлось ни читать, ни писать. И работает быстро. И ещё CLI умеет считать lines of code по проекту, чтобы задать приоритеты. В проектах обычно ставлю максимальную длину файла 700 строк + до 10% превышения, при котором разрезание ещё не срабатывает. Без такой гигиены не будет никакого AI-agent-first. Можно быстро привести к норме легаси-проект или не запустить новый. katana пару месяцев жила во внутреннем репозитории и показала эффективность, теперь переехала на GitHub — могут быть баги. https://github.com/vgmakeev/kanata

Привет! На связи Глеб Панфилов, Head of BA Surf. Сегодня обсудим последние новости о регуляции ИИ. Со 2 августа 2026 года в ЕС заработал ключевой блок EU AI Act. Но ждет ли нечто подобное российский рынок? 26 июля 2026 года подписали федеральный закон, регулирующий разработку и применение больших фундаментальных моделей ИИ. Основные положения вступают в силу уже с 1 сентября 2026 года. Если кратко: ⚫️ Закон вводит механизм добровольной маркировки ИИ-контента. Платформы с трафиком свыше 500 тысяч пользователей в сутки обязаны дать для этого техническую возможность с 1 марта 2027. ⚫️ Добавились статусы «суверенная» и «национальная» модель. Правительство сможет определить сферы, где допустимы только они, — в законе прямо названы банки и финрынок. Самого перечня пока нет. ⚫️ Разрешили обучение на объектах авторского права без согласия правообладателя для разработчиков суверенных и национальных моделей. ⚫️ Закрепили обязанности разработчиков: безопасность, правила эксплуатации, техдокументация. Как итог: шума много, но для заказной разработки по сути ничего не изменилось — новых обязанностей у подрядчика не появилось. Смотреть стоит в другую сторону: выбор базовой модели и происхождение данных. Именно оттуда регулирование однажды дойдёт и до нас, и это дешевле заложить в нефункциональные требования сейчас, чем переделывать на приёмке.

🔥 Привет! На связи Маша Лещинская, и сегодня хочу рассказать про мой новый любимый AI-скилл — Grill Me. Кажется, теперь я использую его вообще везде: в тестировании, разработке и при проработке любых новых идей. Суть Grill Me простая, но невероятно полезная: вместо того чтобы сразу бросаться выполнять задачу, AI начинает буквально прожаривать тебя вопросами. Он уточняет детали, находит противоречия, поднимает неочевидные сценарии и заставляет принять решения, о которых ты сама ещё даже не задумывалась. В тестировании я использую его, чтобы: ⚫️ проверить, не пропустила ли я важные риски и пользовательские сценарии; ⚫️ глубже разобрать требования; ⚫️ продумать проверки, негативные кейсы и пограничные состояния; ⚫️ найти слабые места в тестовой стратегии ещё до начала тестирования. В разработке, чтобы: ⚫️ нормально спроектировать решение до написания кода; ⚫️ разобрать архитектурные варианты и компромиссы; ⚫️ выявить спорные места в логике; ⚫️ не получить от AI код, который технически работает, но решает вообще не ту задачу. И вот это для меня главное: Grill Me помогает правильно сформулировать саму задачу. Проблема большинства AI в том, что они слишком быстро начинают выполнять задачу. Хотя иногда важнее не получить ответ, а сначала задать правильные вопросы. Короче, Grill Me — очень крутой скилл. После такой прожарки решения становятся сильнее, тесты — глубже, а бессмысленных переделок — меньше. Рекомендую всем, кто использует AI в QA, разработке, аналитике или проектировании продуктов.

🔎 Вакансия Product Designer (AI-native) Ищем сильного продакт-дизайнера с опытом работы над цифровыми продуктами — от пользовательских сценариев и визуальных концепций до качественных интерфейсов и реализации на фронтенде. Особенно интересен опыт в Fashion, FoodTech, eCommerce или FinTech. AI должен быть частью вашего рабочего процесса. Нам важен не конкретный набор инструментов, а то, как вы их используете и какой результат они помогают получить. ✉️ Присылайте портфолио в tg, коротко расскажите о себе и обязательно укажите, какие AI-инструменты используете и как они встроены в вашу работу.

Привет, на связи Маша Лещинская, Head of QA Surf. Сегодня ответим на вопрос: «Если AI генерирует тесты, то кто тестирует AI?» Нейросети ускоряют работу QA: они уже умеют писать ручные кейсы, проверки для API и заготовки автотестов. Но скорость не гарантирует качество. Даже если десятки сгенерированных за минуту сценариев и код выглядят идеально на первый взгляд, им всё равно нужна проверка. Но остаются более важные вопросы: ⚫️ покрыты ли критичные пользовательские сценарии; ⚫️ учтены ли пограничные значения и негативные кейсы; ⚫️ правильно ли поняты бизнес-правила; ⚫️ нет ли дублирующих и формальных проверок; ⚫️ действительно ли автотест проверяет нужное поведение; ⚫️ соответствует ли код архитектуре и паттернам проекта; ⚫️ не станет ли сгенерированный тест нестабильным в CI. Поэтому результат работы AI нужно оценивать так же системно, как мы оцениваем качество продукта. Для этого можно использовать eval-фреймворк: набор контрольных задач, ожидаемых результатов и критериев оценки. Например, мы заранее подбираем несколько требований разного типа: ⚫️ форма с граничными значениями; ⚫️ API с обязательными и необязательными полями; ⚫️ функциональность с несколькими ролями; ⚫️ сценарий с неочевидным бизнес-ограничением; ⚫️ задача, для которой уже существуют ручные и автоматизированные проверки. Затем просим AI сгенерировать ручные тест-кейсы и автотесты и оцениваем результат по конкретным метрикам: ⚫️ сколько критичных сценариев найдено; ⚫️ сколько важных проверок пропущено; ⚫️ сколько тестов оказались лишними или дублирующими; ⚫️ какая часть ручных тест-кейсов принята без изменений; ⚫️ сколько автотестов потребовали доработки; ⚫️ сколько времени удалось сэкономить по сравнению с обычным процессом; ⚫️ насколько стабильно AI выдаёт качественный результат на похожих задачах. Такой подход позволяет оценивать AI-инструменты по их реальной пользе. Нейронки быстро генерируют проверки и автотесты, но ответственность за их качество и покрытие остается за специалистом. Как раньше мы тестировали код и продукт, так теперь нам необходимо тестировать и сам AI.

Привет, на связи Вадим Мазин, CBDO Surf. 16 июля рассказывали на Fashion Dive про наши AI-продукты для fashion e-commerce. Честно, такого ажиотажа не ждали: обсуждения в кулуарах заняли больше времени, чем сам доклад. Так что рассказываю подробно здесь. Оба продукта повышают конверсию, устраняя две причины отказа от покупки: неэффективный поиск и недостаток информации в карточке товара. ➡️ Fashion Search — поиск, который понимает моду 90% покупателей не используют поиск: он не понимает естественные запросы. Fashion Search анализирует текст и изображения, распознаёт признаки товара и находит вещи даже по абстрактным запросам: «корпоратив в белом» или «уютная осень». Что это дало Love Republic (A/B-тест на реальном трафике): 🟣 конверсия из поиска в корзину — ×2; 🟣 доля поиска в выручке — ×1,6. ➡️ AI Try-On — примерка, которая выглядит как fashion-съёмка Покупатели не понимают, как одежда будет смотреться на них, поэтому отказываются от покупки или заказывают несколько размеров. Мы создаём персональный аватар, чтобы покупатель мог примерить весь каталог в формате студийной съёмки. Цифры Try-On из живого приложения: 🟣 5% MAU попробовали фичу в первый месяц; 🟣 в среднем 4 примерки на активного пользователя; 🟣 конверсия в корзину после примерки — ×2,3; 🟣 +4% к выручке магазина. Люди привыкли, что ChatGPT понимает их с полуслова. А магазин встречает поиском из 2015 года и карточкой как у конкурентов — разрыв ощущается очень сильно. Оба продукта покажем на вашем каталоге: нужен только товарный фид. Поднимем бесплатное демо, дальше пилот и A/B-тест. Пишите напрямую — @sainor.

Рассказываем, как мы помогли заказчику из финтеха подготовиться к миграции большой легаси-базы с Oracle на PostgreSQL. База здесь — по сути, весь бэкенд: значительная часть бизнес-логики реализована прямо в СУБД, в пакетах PL/SQL, вплоть до отправки писем из базы данных. Основными причинами миграции стали стоимость лицензий Oracle и санкционные риски. Переезд с Oracle — одна из самых тяжёлых миграций. Коробочных решений нет, многое из стека просто не существует в других СУБД, несовместимы даже некоторые типы данных. Перенести код напрямую не выйдет: нужно понимать, что делает каждый участок, и подбирать решение: где-то переписать функцию, где-то вынести логику в отдельный сервис. Именно из-за этой цены переезда многие компании продолжают платить за лицензии Oracle. Вторая сложность — разобраться, что вообще накопилось в базе, которую годами развивали разные команды. Мы провели анализ с помощью LLM и получили карту сложности. Результаты показали, что 90–95% кода можно перенести по типовым сценариям, а наиболее сложная логика сосредоточена в нескольких участках. После этого перешли к пилотному этапу. Сначала перенесли таблицы, затем 140 объектов из пакетов. С ИИ-ассистентами это заняло 20 часов вместо расчётных 62. Отдельно проверили корректность переноса функциональности, связанной с отправкой писем из базы данных. По итогам проекта заказчик получил карту сложности всей базы, результаты пилотной миграции, план дальнейших работ и оценку полной миграции в 1200–2000 часов. LLM втрое ускорили пилотный перенос и заметно сократили время анализа, так мы быстрее оценили объём работ и перешли к планированию. Если вы планируете миграцию между любыми другими СУБД, то мы поможем оценить объём работ, сроки и риски на основе анализа вашей базы данных, а при необходимости возьмём работы по переносу на себя. Пишите напрямую @sainor

Директорат Surf на Fashion Dive — удваиваем конверсию в fashion e-com 16 июля Владимир Макеев, CEO Surf, и Вадим Мазин, CBDO Surf, выступят на конференции Fashion Dive в Москве и расскажут, как наши AI-решения помогают увеличивать выручку клиентов. ➡️ Fashion Search — умный поиск, который анализирует фотографии товаров. Он распознает нюансы кроя, стиль и понимает абстрактные запросы вроде «корпоратив в белом» или «уютная осень». ➡️ AI Try-On — виртуальная примерка, благодаря которой покупатель видит вещь на себе ещё до оформления заказа. Инструмент помогает снять сомнения перед покупкой и снижает долю возвратов. Если хотите пересечься в Москве, чтобы обсудить ваши проекты, или встретиться на самой конференции, пишите напрямую Вадиму — @sainor.

Привет, на связи Глеб Панфилов, Head of BA Surf. Сегодня обсудим путь и роль современного аналитика в эпоху ИИ. Аналитика всегда несла в себе риски человеческого фактора. Но с появлением новых моделей с большим контекстным окном они сводятся к минимуму. Давайте подробно пройдемся по этапам: 🟠 Бриф и первичное погружение Вместо долгого ручного сбора требований исходные документы теперь загружаются в ИИ. Нейросеть сама выявляет нестыковки, формирует доменную модель и готовит вопросы заказчику. В результате бизнес сразу видит риски, а время погружения сокращается. 🟠 Анализ и формирование спецификации Нейросети позволяют формировать, приоритизировать и трассировать требования, обеспечивая заказчику полную прозрачность скоупа и бюджета: в ТЗ попадают только обоснованные фичи. Чтобы минимизировать галлюцинации ИИ, мы декомпозируем задачи и постоянно очищаем контекст. 🟠 Проектирование артефактов Описание API и пользовательских сценариев вручную занимали много времени. ИИ автоматизирует создание технической документации. Аналитик выступает в роли архитектора, подробно отсматривая и доводя результат, что ускоряет подготовку артефактов и сокращает общий Time-to-Market продукта — об этом мы писали в статье. 🟠 Валидация и передача в разработку Самые сложные и негативные сценарии могли всплыть уже во время написания кода, блокируя спринты. Теперь можно прогнать спецификацию через ИИ в режиме кросс-ревью для поиска противоречий и пропущенных ошибок. В разработку уходит выверенный документ, команда и заказчик не тратят часы на выяснение блокирующих вопросов. Резюме Роль аналитика остается ключевой, так как он погружен в проект больше ИИ. Пока нейросеть берет на себя механическую работу и поиск ошибок, аналитик отвечает за архитектуру и бизнес-логику. В результате заказчик получает готовую работу быстрее, с прозрачной документацией и без упущенных деталей.

Итоги Рейтинга Рунета для Surf — гордимся командой и благодарим клиентов В этом году мы снова доказали экспертизу в мобильной разработке. Забрали награды и восхищаемся всеми, кто помог достичь этого результата. Наши команды разработки, анализа, тестирования и дизайна, проджекты, девопсы — все они подтвердили профессионализм и оправдали доверие клиентов. 🏆 Достижения Surf в рейтинге: 🟠 3 место — «Подрядчики с экспертизой в отрасли Питание (разработка, интеграция)». 🟠 4 место — «Разработка и развитие мобильных приложений». 🟠 8 место — «Подрядчики с экспертизой в отрасли Торговля (разработка, интеграция)». 🟠 9 место — «Подрядчики крупного бизнеса (разработка, интеграция)». Планка поднята высоко, в нише заказной разработки участвовали более 1000 агенств, но останавливаться мы не планируем. На полке ещё полно места для наград. Ознакомиться с кейсами, которые принесли нам классные результаты, можно на сайте.

Привет, на связи Глеб, Head of BA Surf. С 1 июля 2026 года белорусский ВТБ полностью переходит на PWA (Progressive Web Apps): приложение под Android доступно только до этой даты, дальше никакого натива. Сразу оговорюсь: это Беларусь, но вопрос напрашивается сам собой — почему бы всем нашим банкам не перейти на PWA? Поэтому разберём не только минусы PWA как технологии, но и в конце прикинем, насколько этот сценарий реалистичен для банков РФ. Безопасность остаётся на уровне веба Это пункт, который почему-то забывают, хотя для банка он первый. Нативное приложение хранит ключи и токены в аппаратном хранилище (Secure Enclave, Keystore), умеет проверять сертификаты, имеет защиту от подмены кода. У PWA в песочнице браузера ничего этого по сути нет, а код и данные куда доступнее. Пуши, от которых зависит вход и сохранность денег В финтехе пуш — это второй фактор подтверждения операции. На iOS у PWA они работают нестабильно: появились поздно, требуют установки на домашний экран и отваливаются после обновлений. NFC и собственные платёжные сценарии Привязать PWA к бесконтактной оплате или чтению NFC-меток на iOS невозможно — там NFC заблокирован под Apple Pay, а на Android поддержка крайне ограничена и требует натива. Для банка это сразу закрывает собственные tap-to-pay, платёжные стикеры и часть транспортных сценариев. Стоит ли нам перенимать этот подход Частично сценарий у нас уже случился: на iOS подсанкционные банки живут без App Store с 2022 года, и владельцы iPhone и так используют PWA. Но на Android расклад другой — есть RuStore и AppGallery, и банки в нативное приложение как раз вкладываются: тот же ВТБ в апреле 2026 выкатил полностью обновлённое приложение и пообещал развивать его весь год. Это прямая противоположность белорусскому «убираем натив». Пока в России работает нативный канал через RuStore, добровольно отказываться от него ради скорости релизов смысла мало, а для экономии бюджета лучше использовать Flutter. Так что белорусский кейс — это скорее живой эксперимент, за которым стоит понаблюдать.

Привет! На связи Диана Игнатович, CMO в Surf. Сегодня расскажу про мои любимые задачки в маркетинге и deep search. Реальность такова: мы (несчастные люди) уже никогда не сделаем ни одно исследование лучше, чем Claude в режиме deep search за полчаса. Даже если вы супер-скилловый аналитик, топ-1 маркетолог в мире и богом поцелованный ресерчер. Это тот раздел маркетинга, где мы проиграли бесповоротно и навсегда. Уровень 1 — конкурентный анализ по сайтам Кидаете список топ-10 конкурентов (наших, зарубежных), натравливаете Claude. Он идет, прокликивает все кнопки, изучает ценообразование, фичи, программы лояльности — и отдает сводную таблицу. Туда же — карта болей: «Собери все жалобы на онлайн-конструкторы кухонь в IKEA», и он сходит в App Store, Google Play, Reddit, TikTok, прочитает отзывы, классифицирует по типам проблем. Уровень 2 — стратегии и позиционирование конкурентов Claude анализирует отзывы, рекламные кампании, соцсети, выступления сотрудников на конференциях. Изучает чужую маркетинговую и продуктовую стратегию — по релизам видно, в какую сторону компания разворачивалась в последние годы, что усиливала, что выпиливала, где ее хвалят, где ненавидят. Идеально, чтобы: ⚫️ отстроиться своей стратегией от конкурентов; ⚫️ взять на вооружение лучшие практики; ⚫️ без лишних усилий следить, кто что делает на рынке. Уровень 3 — продуктовый анализ Например, у вас сервис по созданию брендированных товаров на заказ. Claude найдет еще десять таких в России и за рубежом, досконально изучит каждый конфигуратор, каждую функцию. Сравнит, отрисует гигиенический уровень рынка, покажет сильные и слабые стороны вашего продукта. Дальше говорите: «Хочу такой же умный AI-конфигуратор, как у вон тех ребят», — и он распишет, что нужно для разработки и сколько часов уйдет под ваш стек. Уровень 4 — археология через Wayback Machine Claude вытаскивает архивные версии сайтов и сопоставляет их между собой. Просите: «Проанализируй сайт Lamoda за последние 5 лет». Получаете карту стратегических разворотов — когда они начали жать на скорость доставки, когда делали редизайн и под что, когда выпиливали категории, когда переобувались в позиционировании.

Привет, на связи Маша Лещинская, Head of QA Surf. Обсудим, как эффективно проверять код, сгенерированный AI. ИИ генерирует фичи за минуты: от 8 в день, и более 50 файлов. Это много, но чтобы проверить качество каждой, недостаточно прочитать код и увидеть зелёные тесты, нужна система. Типичные ошибки ИИ, с которыми будем бороться: ⚫️ галлюцинации; ⚫️ пропуск пунктов задачи; ⚫️ некорректная реализация; ⚫️ «зелёные» автотесты, которые проверяют не то; ⚫️ неточное селф-ревью, пропускающее баги. Решение — сквозной пайплайн из 4 шагов: 1) Финализируем требования. 2) Сводим всё к единому формату проверок — общий язык для человека, агентов и автотестов (приемочные тесты + openspec). 3) Генерим автотесты и делаем трассировку (ID связывает требование, код и тест). 4) Прогоняем против ИИ-кода — матрица быстро покажет, что работает. Главные вопросы и ответы: Зачем вообще нужны ручные тесты, если ИИ должен избавлять от ручной работы? Ручные кейсы пишет агент, а не человек. Это человекочитаемый слой между требованием и автотестом: каждый кейс 1:1 превращается в e2e. Чем плотнее слой, тем меньше живого ручного теста. Это способ сократить ручную работу, а не раздуть её. Количество тестов — цифра ни о чём. Как мерите пользу? Важно не количество тестов, а их способность находить дефекты. Через фильтр quality-gate проходят только тесты, которые стабильно падают на реальных багах, имеют внятный ассерт, покрывают негатив/edge-cases и устойчивы к косметике UI. Силу базы оценивают мутационным тестированием, полностью игнорируя line-coverage, ведь покрытие строки не означает проверку результата. Какой coverage? Покрытие требований — 100% (от известных, поэтому рядом всегда поиск аномалий в графе + ревью ТЗ человеком). А автоматизация около 90% кейсов, часть осознанно остаётся на руках. Кто ревьюит код? Основное делают гейты: TDD RED/GREEN, self-review по 7 измерениям (агент с чистого контекста, не автор кода), ограничение diff по задаче, привязка к требованиям, финальный гейт (линтер + тесты + smoke + архитектура). Человек смотрит не код, а их выходы: отчёты, матрицу, логи. Агент сам чинит правильный тест — как бороться? Обязательное условие: перед правкой агент сверяет тест со спекой и отвечает, кто неправ — код, тест или спека неоднозначна. Ослаблять/удалять ассерты, скипать или мокать баг запрещено. Любая правка ассерта видна в diff и матрице, там подключается человек. Выводы: ИИ выполняет большую часть работы, а человек подключается только к ключевым задачам (ревью, спорные случаи). Это позволяет одному разработчику вести сразу несколько фич, сохраняя и скорость, и качество. Без такой системы гарантировать успех продукта на 100% уже невозможно. Метрики привела на картинке ниже.

Сегодня расскажем, как наш разработчик синхронизировал конфиги ИИ-ассистентов для двух разных проектов. У заказчика было два приложения: клиентское и курьерское. Для Claude и Cursor мы пишем кастомные рулзы и промпты. Пока всё лежало в одном проекте, проблем не было. Но как только появился второй репозиторий, копипастить масштабные изменения стало тяжело. Дублировать конфиги руками — тоже не лучший вариант. В итоге один из разработчиков придумал схему: Вынес все общие правила и скиллы в отдельный репозиторий и подключил его к обоим проектам как git submodule. А чтобы ИИ-инструменты видели конфигурации там, где привыкли, в корне проектов настроил симлинки на подпапки сабмодуля. Ассистенты думают, что работают с локальными файлами, хотя физически всё пишется в общую базу. При этом файлы адаптации под конкретный проект (CLAUDE.md и локальные настройки settings.local.json) намеренно оставили уникальными для каждого приложения и в сабмодуль не включали. Вместо обычных bash-скриптов он написал кастомные скиллы Claude. Теперь процесс выглядит так: Разработчик правит правило через симлинк в корне проекта. По команде пользователя Claude запускает скилл, создает ветку в сабмодуле, стейджит изменения и делает коммит с трейлером Co-Authored-By. Каждый шаг требует подтверждения человека. Claude пушит ветку и выводит ссылку на MR в репозитории правил, после чего бампает хэш сабмодуля в основном проекте. Как итог: промпты всегда актуальны на обоих проектах, а команда больше не тратит время на копипаст.

Привет, это Маша Лещинская, Head of QA Surf. Большинство попыток ускорить написание тестов с помощью нейросетей заканчиваются одним из двух: либо AI пишет код, который всё равно приходится переписывать, либо человек тратит на промпты больше времени, чем ушло бы на ручной код. Причина: AI плохо работает без системы. Есть три уровня AI-генерации тестов: ⚫️ В лоб («напиши тест для логина»). Дает ускорение в 1.5 раза. По сути, это просто ускоренная ручная работа, требующая доработок. ⚫️ По user flows и структуре экранов. Дает уже 3–5 раз. ⚫️ По живому коду приложения. Когда AI видит реальные компоненты и accessibility labels, ускорение в 8 раз и выше. Но всё это работает только при одном условии: вокруг агента должна быть выстроена система. Для построения системы мы собрали: Мета-фреймворк, который генерирует E2E-проекты под шесть платформ: Web (Playwright), Flutter, iOS, Android (Kaspresso), Appium, API (pytest). Единые правила, пять шагов генерации, два quality gate и оркестратор с параллельным запуском агентов. Процесс генерации, состоящий из пяти шагов. В цикл входят: Page Objects, Tests, Mocks, Reporting, Review. Модель видит только нужные ей файлы — это исключает выдумывание зависимостей. Правила, которые работают, потому что их проверяют скрипты, а не люди. Preflight валидирует промпты на ошибки до старта, а Postflight анализирует готовый код (заканчивается ли assertion, нет ли Thread.sleep и TODO). За параллелизацию отвечает оркестратор: он берет задачи из kanban.md и раскидывает их по отдельным git worktrees. Агенты одновременно создают Page Objects для разных экранов, а тесты идут следом. Синхронная работа четырех таких агентов как раз и дает реальный прирост в 8 раз. Главное правило из двенадцати Тест заканчивается проверкой, а не действием. Звучит очевидно, но большинство нестабильных E2E умирают именно так: что-то кликают, но ничего не валидируют. Gate блокирует merge при нарушении. Ревью по-прежнему необходимо — система не решает, какие сценарии критичные и где нужны моки. Но теперь это ревью PR от коллеги, который знает правила: базовые нарушения уже отсеяны.