Когда вайб-кодинг реально даёт профит?

2 года назад в Surf мы делали большой внутренний эксперимент. Его итогом стал мой доклад “Внедрение AI в процессы разработки”.

С тех пор появилось множество новых исследований. Но странно — даже в 2025-м всё ещё ссылаются на старые цифры GitHub о "повышении продуктивности на 55%".

Разберёмся.

Цифры — не голый маркетинг, под ними есть реальное исследование. Эти 55% — это не от нуля и не по всем стадиям разработки. Это прирост только на стадии “кодим”, когда всё уже понято, спроектировано, уточнено, а в голове есть решение. То есть — после общения, проектирования и уточнений.

И ещё нюанс: 55% — это не "в два раза больше", а всего лишь x1.55.

Если в вашей работе кодинг — это 20% (что немало, если смотреть уже это исследование), а всё остальное — обсуждение и проектирование, то реальный прирост — всего на этих 20%. А значит — не такой уж и фантастический.

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

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

Я прихожу к двум косвенным выводам:

1. Чем больше в вашем рабочем дне кодинга, тем проще вас заменить. Если уже сейчас вам почти не нужно ничего думать и обсуждать перед выполнением задачи, это повод задуматься, потому что ChatGPT тоже это не нужно.

2. Чтобы получать пользу от AI, нужно повышать эффективность коммуникации. Самый простой способ — уменьшать количество людей в команде и прослоек между заказчиком и исполнителем.

AI не спасает плохой процесс. Он усиливает хороший. И если вы не начнёте с коммуникации — никакая модель не вытащит.

🏁Гонка UX, а не гонка моделей

Помните, каким был ChatGPT в 2022-м? Это выглядело как курсовой проект студента: ни истории, ни реактивности, ошибки — сплошная чернота, интерфейс — боль.

Сегодня это — эталон UX и UI в своей категории.

Все эти годы Copilot продолжал использовать древнюю CodeX, но оставался лидером. Почему? Потому что конкуренты гнались за топовыми моделями, а не за удобством.

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

Это именно тот сдвиг, которого я ждал. Это значит: Cursor — только начало. Нас ждёт волна по-настоящему продуманных, классных AI-инструментов.

“Опасный Flutter… Или нет?”

В этом посте все материалы и источники по моему выступлению на Mobius 2025 Spring.

🐮 Подписывайтесь на канал Flutter-команды Surf

Кейсы:

1. Как Starbucks хранил логины и пароли в открытом виде
2. Как Snapchat слил базу контактных данных 4.5 миллионов пользователей
3. Как Покемоны пытались получать слишком много разрешений

Упоминания:

�� OWASP TOP-10 2024
👩‍💻 Статья “How Classical Attacks Apply to Flutter” от Guardsquare (3 части)
🇰🇵 Атака северокорейских хакеров на macOS
🌐 Выступление Юрия Шабалина “Мифы и легенды о безопасности мобильных приложений” (о Flutter на 31 минуте)
🛡 Крутейшая методичка по безопасности МП от Stingray

👩‍💻 Самый известный ревёрсер Flutter-приложений — reFlutter
👩‍💻 Статья “Fork Bomb for Flutter” от автора reFlutter
👩‍💻Примеры RASP: freeRASP и safe_device

🔫 Статья о способах атаки на Flutter-плагины
🔫 Об атаке через библиотеку event-stream
🔫 Об атаке через библиотеку node-ipc
🔫 Об атаке через библиотеку Log4j

🔑 Отслеживание статуса миграции flutter_secure_storage на новый способ хранения
🔑 Объяснение, почему вы не должны использовать AES/CBC/PKCS5Padding для шифрования чувствительных данных
🔑 Чем отличаются параметры доступа к данным в Keychain
🔑 Подробнее об аппаратном шифровании Secure Enclave на iOS

🪣 Способы обхода биометрии на iOS
🍏 Способы обхода биометрии на Android
👩‍💻 Рекомендуемые альтернативы для local_auth: biometric_storage и biometric_signature.

Как поддерживать форму, когда стал руководителем?

Кодинг — это не езда на велосипеде. Тимлид (да и любой технический руководитель) всегда приносит в жертву свои профессиональные навыки. Ведь научившись однажды, ты не будешь таким же крутым, как те, кто делает это постоянно. Забавно, но это делает тимлида зачастую худшим разработчиком в команде, вопреки мнению, что он должен быть самым крутым.

Последние 2 года моими хард-навыками стали умение форматировать заголовки в Confluence и знание формул в Google Sheets, а 80% моего рабочего дня состояло из митингов и их протоколирования. Но пару месяцев назад мне представилась возможность вернуться к корням — потимлидить НАСТОЯЩИЙ проект и даже пописать там код.

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

Я проанализировал свои практики и вот что мне помогало поддерживать форму больше всего:

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

🤢 Багофикс. На самом деле, я немного слукавил, когда говорил, что не кодил последние 2 года. Я активно приходил на проекты для багофикса, если это было необходимо: не хватает ресурсов, разработчик заболел или кто-то ушёл из компании и мы не успели подобрать замену. Багофикс это ещё и очень крутой способ заонбордиться в новый проект. Ничего так не даёт представления о коде незнакомого проекта, как попытка починить что-то в нём.

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

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

Тимлидский синдром вахтёра

Что является гарантом власти тимлида? Зачастую, тимлид это просто человек, которому кто-то сказал, что он теперь тимлид. Это не предполагает какие-то полномочия закреплённые в договоре, не наделяет его властью увольнять, нанимать или выдавать зарплату (по крайней мере, напрямую). Поэтому, мне кажется, что гарантом власти тимлида является его авторитет в команде.

Что происходит, если тимлид не чувствует для чего он нужен или не чувствует какой-либо власти в управлении командой? У него развивается синдром вахтёра.

Самое частое проявление такого синдрома, которое я встречал — проявление власти в местах, где у тимлида есть хоть какие-то реальные ограничения. Например, пулл реквесты, где тимлид, как настоящий вахтёр, решает, пускать ли тебя в master (за расизм извините).

Тимлид-вахтёр обязательно будет докапываться в вашем код-ревью до каждой пустой строки после return и ставить клоунов 🤡, когда вы в очередной раз забываете, что вам нужно ставить trailing comma. Да, вас это раздражает. Ну и что? Он не прав, что ли? Это же ваш код-стайл.

Естественно, он не прав. Паттерном поведения хорошего лидера будет скорее договориться об изменении код-стайла или доказать своим авторитетом, что он прав и вам необходимо это делать.

Но это будет паттерном поведения хорошего лидера, а не профессионального тимлида. Профессиональный тимлид никогда не будет делать вам одни и те же замечания по код-стайлу. Тем более, он никогда не будет делать работу, когда её есть возможность делегировать. Особенно, если такую работу можно делегировать роботу — вашему анализатору (линт-рулам) и CI/CD.

Если ваш тимлид докапывается до вас на код-ревью по код-стайлу, напомните ему, что его время слишком дорогое, чтобы заниматься этим. Пусть докажет, что он не только лидер, но и технарь, и напишет вам хороший линт-рул. Мы в Surf, помимо кастомизации стандартных правил от Flutter, используем DCM, для которого тоже написали свои пресеты. Подобные инструменты есть, пожалуй, для каждой технологии (Detekt, ESLint, SonarQube).

P.S.: вахтёр на английском “watchman”, то есть “Хранители” на самом деле “Вахтёры”.

Я и Шаман — один человек?

Похож ли тимлид на клей? Что важнее: свобода разработчиков или строгие процессы?

Ответы на все эти вопросы вы узнаете во втором эпизоде подкаста "Не 12 часов" на 📺 YouTube или �� VK Видео.

Программисты пишут не только код

Пожалуй, один из самых недооцененных навыков среди инженеров (по крайней мере, в СНГ) — техническое письмо.

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

Flutter очень высоко задрал планку с точки зрения документации кода. Насколько, что у на сайте Dart есть целая статья, посвящённая тому, что вам нужно отделять заголовок, абзацы, ставить точку в конце и выделять код в Markdown (да, “духота” запредельного левела). А в DCM есть целые правила.

Мои навыки сформировались скорее под действием опыта. В подростковом возрасте я писал статьи про футбол и мечтал попасть на главную Sports.ru. А уже будучи разработчиком писал как статьи на технические темы, так и методички для университетов. Навык ещё продолжает формироваться, помогая в том числе писать огромную базу знаний производственных процессов (тут Женя рассказывал об этом). Тем не менее есть материалы, которыми я готов поделиться:

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

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

3. Немного оффтоп, но есть лекции (клац и шмац) на тему, как писать так, чтобы вас понимали. Тоже будет не лишним при формировании опыта.

P.S.: когда-нибудь сделаю пост про протоколы и их важность в работе и приложу фотку Сталина, а пока держите Чехова