Собрал на Google AI Studio небольшой визуальный проект. Честно говоря, без конкретной цели, просто ради эксперимента: посмотреть, как поведет себя Gemini на странных запросах.

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

Но вот с чем я сталкиваюсь постоянно — это повторяющиеся ошибки вида «Minified React error #300...». И тут сразу видно, что React для меня темный лес. Влезать в его изучение только ради того, чтобы вручную разбирать такие баги — совсем не то, ради чего я затевал эксперимент.

Из жизни вайбкодинга: куда уходят кредиты в V0. Залез в статистику и посчитал, как тратятся кредиты в V0. Если смотреть на стоимость миллиона токенов, то V0 находится примерно на уровне средних моделей OpenAI и Anthropic. В конечном счёте, под капотом там работает Claude 3.5 (для больших запросов модели поновее), как сама сеть призналась в одном из моих запросов. Так что дешевле оно и не может быть.

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

Дешевые запросы:
- старт проекта без истории,
- стилистические правки в готовом проекте (но надёжнее делать руками),
- справочные вопросы без генерации кода.

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

Вывод: если нет задачи собрать цельный проект и «шлифовать» его, то выгоднее генерировать решения с нуля. Пересоздать проект новым промптом может оказаться дешевле, чем вносить правки в старый.

David Kossnick из Figma написал о большом обновлении.
Похоже, оно сделает работу над дизайном еще проще.

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

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

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

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

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

Больше о технологии в публикации Skin-attached haptic patch for versatile and augmented tactile interaction

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

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

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

В качестве отступления: у YC (еще со времени управления Сэмом Альтманом) есть хорошие лекции о том, как делать стартапы, и у Harvard Innovation Labs есть отличные материалы по этой теме.

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

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

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

Они верят, что одной идеи достаточно, чтобы захватить рынок. Верят в безошибочность своей идеи. Они уверены, что знают пользователей, и не стремятся более четко определить целевую аудиторию. Учиться им тоже неинтересно.
Мне думается, что вопросы и сомнения, которые я поднимаю в обсуждениях, воспринимаются как сопротивление и торможение для их «прекрасной идеи».

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

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

На обложке один из слайдов лекции Майкла Скока (Michael Skok) про роудмап успешного стартапа.

Национальное бюро экономических исследований (NBER) опубликовало большое исследование об использовании ChatGPT в США. Данные собирали в течение длительного времени, и там много интересного.

Меня же зацепили два факта.

Первый: среди ранних пользователей ChatGPT преобладали мужчины. Возможно, это отголоски нашего «первобытного» инстинкта — первыми переться в незнакомую чащу. Но сейчас использование почти выровнялось по гендеру. А это может значить, что LLM уже стало привычной областью, которую приняло общество.

Второй: доля использования ChatGPT для программирования невелика — всего 4,2%. Почти столько же, сколько доля занятости в ИТ среди взрослых американцев (по разным оценкам — это около 2%). Получается, большие языковые модели уже стали универсальным инструментом, а не чем-то нишевым.

Доклад по ссылке How People Use ChatGPT

Использование LLM несет не только пользу, но и издержки.
Речь идет о двух исследованиях 2025 года «Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task» и «The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers».

Первое исследование изучало влияние LLM на студентов в процессе написания эссе. Оценивали как итоговые тексты, так и когнитивные изменения при помощи электроэнцефалографии и опросов. В результате оказалось, что постоянное использование LLM снижало нейронную связность, ослабляло память и снижало чувство авторства. Итоговые работы становились менее разнообразными и менее креативными. Зафиксированное снижение когнитивных способностей исследователи назвали «когнитивным долгом». Речь идет не о том, что люди «тупеют», но об устойчивом снижении вовлеченности и самостоятельности, что и показали результаты исследования.
Второе исследование проводилось среди работников, которые регулярно используют генеративные ИИ в повседневных задачах. Вывод похожий: при высокой уверенности в ИИ и низкой уверенности в себе уменьшается объем критического мышления. Люди начинают меньше времени тратить на решение задачи и больше времени на интеграцию решения в рабочий процесс. Такая перестройка процесса в долгосрочной перспективе может снижать способность к самостоятельному решению задач.

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

Немного про эффективность сотрудников и влияние состава команды на успех проекта.

Наверное не будет ошибкой сказать, что от качества команды зависит успех проекта. При этом реальную производительность измерить непросто. Поэтому придумывают множество метрик и методик (ревью, KPI, OKR и пр.). В свое время, меня особенно впечатлила презентация Construx Software , посвящённая индивидуальной эффективности программистов и влиянию организационных моделей работы на результаты.

Согласно классическим исследованиям, между лучшими и средними программистами есть огромная разница. Даже с учетом разных условий (языков, опыта, типа работы) разрыв остается значительным — от 5 до 10 раз. Есть обзоры, которые заявляют о еще большем разрыве.
Зато влияние методологии работы обычно намного скромнее. По данным Project Management Institute, при грамотном применении гибридного подхода (комбинация Agile, Waterfall и пр.) производительность проектов сравнима с любой отдельной методикой. Иными словами, удачные методики повышают эффективность, но в гораздо меньшей степени, чем разница между людьми. Обычно называют улучшение в пределах 20-40%.

Что из этого следует на практике? Если в команде есть «звёзды», опытные сотрудники с высоким профессионализмом, то они будут решать задачи заметно быстрее и качественнее любых других членов команды, независимо от используемого процесса или методологии. И наоборот, если в команде в основном «средние» специалисты, то и результат окажется посредственным, какие бы практики вы ни внедряли. Наибольшие изменения происходят именно при смене состава команды, а не при смене методологии.

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

Когда воображение не справляется с перегрузкой. Недавно наткнулся на исследование (The capacity limits of moving objects in the imagination) о том, как мы отслеживаем объекты в воображении. Суть исследования была проста, испытуемых просили представить окончания событий, которые они не видели целиком, событием были движущиеся объекты.

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

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

Игровые интерфейсы? Возможно. Но думаю, там это давно известно на уровне эмпирики.

В других областях когнитивная перегрузка давно уже используется, например, у тех же фокусников. Да и даже Гурджиев построил свою практику танцев на когнитивной перегрузке.

В итоге остаётся ощущение, что исследование скорее подтверждает то, что люди интуитивно знали давно.

О разнице между фактическим временем выполнения задачи и календарным временем проекта. Недавно работал над небольшой задачей. По факту ушло 9 часов чистой работы. По календарю - 22 дня.

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

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

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

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

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

В итоге: Задача решена. В эстимейт уложился (он был 2-12). Проект длился три недели, кажется, что не быстро, но никто не торопил. Команде придется доработать дизайн-систему под новые элементы: дополнительная работа для дизайнеров и разработчиков.

Общий результат по задаче не лучший, но, как по мне, вполне рабочий. Из выводов - нужно быть честным в оценке и учитывать не только “сколько займёт сделать”, но и “сколько займёт согласовать”.

Еще один простой эксперимент в Figma Make c вайбкодингом. Ничего конкретного, просто ради забавы. У меня на текущий результат ушло 13 запросов, в основном, чтобы уточнить физику объектов. Но, если вы захотите попробовать у себя такое сделать, то вот вам краткий промт:

Создай веб-приложение с полноценной 2D физической системой из 15 квадратных блоков разного размера и цвета. Блоки подчиняются гравитации, имеют инерцию и трение, отскакивают от границ контейнера с коэффициентом восстановления. При столкновении блоков друг с другом происходит отражение вектора движения с передачей импульса - неподвижный блок получает часть энергии движущегося по направлению первоначального вектора с коэффициентом затухания 0.4, что создает эффект домино и цепные реакции.

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

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

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

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

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

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

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

В выступлении «Building Faster with AI» на Youtube доктор Эндрю Нг (Andrew Ng) делится принципами, которые помогут стартапам двигаться быстрее при создании продуктов при использовании ИИ. Я пару выписал:

Работайте с конкретными идеями, которые достаточно детализированы, чтобы их можно было воплотить в конкретное решение. Например, «приложение для онлайн-бронирования в больницах», а не «оптимизация здравоохранения с ИИ». Абстрактные идеи кажутся увлекательными, но тормозят процесс.

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

Когда у вас много гипотез, фокусируйтесь на одной, но отказывайтесь от неё, если данные показывают ошибку в выбранном направлении, и берите в работу следующую.

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

Если для разработки кода ИИ ускоряет работу на 30–50%, то при работе над грубыми прототипами ускорение в 10+ раз. Этим надо пользоваться.

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

Код уже не так ценен, как раньше, не надо за него цепляться.

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

Бутылочное горлышко продуктов сдвигается от инженерии к менеджменту. Если раньше на одного PM приходилось 6–7 разработчиков, то, возможно, мы двигаемся к ситуации, когда соотношение будет 1 к 0,5.

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

Немного про А/Б тестирование.
Компания добавила фильтр «Какой размер вам нужен?» на страницы с товарами (обувь) в верхней части каталога. Целью было упростить выбор, опираясь на закон Хика: чем больше вариантов одновременно приходится обрабатывать, тем дольше принимается решение.

С одной стороны, фильтром активно пользовались (29% click rate), но в целом результат оказался негативным

Ключевые метрики резко упали:
Доход на пользователя: -8,38%; Конверсия: -5,21%;
Средний чек: -3,26%;
На десктопе падение дохода достигло -14,02%.

Компания считает, что причиной падение стало то, что иногда большой выбор – это хорошо.

При всей интересности кейса к нему можно задать несколько вопросов.

- Насколько корректно был спланирован A/B-тест? Без понимания технической составляющей того, как проводилось тестирование, трудно оценить его достоверность.

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

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

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

Я решил попробовать перенести исполняемые скрипты из вайбкод платформы в no-code. В моем случае: из Figma Make во Framer (вот что вышло).

Framer выбрал почти случайно. Сначала думал про Webflow, но там в бесплатной версии нет доступа к кастомным блокам. А во Framer они есть — и это решило вопрос.

Сам процесс выглядел так:

Сначала сделал копию разработанного проекта в Figma Make, чтобы не поломать исходник. Потом попросил систему переписать код под интеграцию во Framer. Она выдала отдельные файлы для компонентов и инструкцию по переносу. Так как с Framer я до этого не работал, то это оказалось очень полезно.

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

Пробовал уточнить через Figma Make, но ответы были путаные. Жаль, что во Framer нет встроенного агента для правки кода. Пришлось идти в обход. После пяти неудачных попыток ChatGPT выдал рабочий вариант кода.

Результат можно посмотреть по ссылке: https://joyous-task-391568.framer.app/

Выводы:

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

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

Немного о брендинге. Недавно наткнулся на исследование 2023 года «The effect of brand names and logos’ figurativeness on memory: An experimental approach». Оно изучало, как название бренда и логотип влияют на три вещи: запоминание (recall), узнавание (recognition) и ассоциации (associations).
В эксперименте использовали вымышленные бренды. Меняли названия и логотипы, смотрели, как люди реагируют. Результаты оказались для меня интересными.

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

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

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

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

Правильно подобранные название и логотип дают компании фору пользовательского внимания. В два раза больше внимания и узнаваемости — это серьезное преимущество. И, используя данные исследования как референс, можно посчитать ROI и другие показатели, связанные с вложением в бренд.

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

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

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

Посмотрел OpenAI DevDay 2025.
Впечатляет, как далеко шагнули возможности ChatGPT.

Apps in ChatGPT открывают новый уровень интеграции, теперь приложения смогут использовать LLM напрямую, а сами модели, работать внутри них.

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

Для разработчиков самое интересное — Codex. Он обещает упростить создание ПО и, похоже, серьезно изменить рынок. Не знаю, разрушит ли он вайб платформы, но конкуренцию точно усилит. Уже сейчас видно, что время на разработку новых продуктов можно смело сокращать вдвое. Хоть найти product-market fit все так же непросто, но создавать продукты стало куда легче.

Лучше, конечно, посмотреть самим и составить свое мнение https://www.youtube.com/watch?v=hS1YqcewH0c

Еще хочу обратить внимание на один фрагмент из выступления доктора Эндрю Нг (Andrew Ng) «Building Faster with AI» на YouTube.

В нем он рассказывает про то, как собирать обратную связь о продукте — и насколько это важно, чтобы принимать правильные решения.
Я отметил этот фрагмент потому что часто встречаю материалы, где специалисты уверяют: «надо глубоко погружаться в исследования, иначе никак». А мне ближе подход Эндрю Нг, когда есть понимание, что можно использовать разные способы получить фидбэк, и у каждого способа своя точность и скорость, и в стартапе приоритет лучше отдавать скорости. Недаром он говорит о том, что в AI Fund запускают в среднем один стартап в месяц.

Варианты получения отзывов о продукте:

- Поиграться с продуктом самому (самый быстрый способ, 10 минут).
- Попросить мнение у 3 друзей или коллег (~ 0,5 дня).
- Спросить 3–10 незнакомцев, например, в кафе или в лобби отеля (~1 день).
- Отправить прототип группе из ~100 тестировщиков (~1 неделя).
- Отправить прототип 1 000 пользователям, чтобы получить качественные или количественные отзывы (~2 недели).
- И, наконец, полноценный запуск с A/B-тестом. Это самый медленный вариант, хотя часто о нем говорят как о лучшем и самом точном решении (2+ месяца).