В выступлении «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+ месяца).

Про Walmart, OpenAI и причем тут Клейтон Кристенсен. Walmart заявила о партнерстве с OpenAI, чтобы продавать товары прямо в ChatGPT. Это событие оказалось настолько значимым, что подтолкнуло акции Walmart на 5 % вверх, а это ни много ни мало, прирост почти на 41 миллиард долларов.

Финансовые аналитики позитивно восприняли новость, а на Reddit к ней отнеслись в основном скептически. Популярно мнение, что это следствие раздувания ИИ-пузыря и никакой новой ценности в сотрудничестве компаний не будет.

Но очевидно, что сотрудничество OpenAI с крупнейшим в США ритейлером — это продолжение стратегии по интеграции покупок в чат через функцию Instant Checkout, которая позволяет оформлять и оплачивать покупки прямо в чате.

Сам Instant Checkout представляет собой протокол агентской коммерции, который позволяет любому розничному продавцу или бизнесу интегрировать свои товары в ChatGPT. И этот протокол может стать началом нового этапа в развитии онлайн-торговли: подорвать доходы поисковиков, подорвать позиции маркетплейсов, поменять правила игры для всей онлайн-торговли. В общем, пример подрывной инновации.

Подрывная инновация — это создание нового способа взаимодействия с продуктом или брендом, который делает старые подходы устаревшими. Идея подрывной инновации была предложена Клейтоном Кристенсеном (Clayton M. Christensen) в 1995 году и подробно описана в книге «Дилемма инноватора» (The Innovator’s Dilemma). Книга есть на русском языке и считается бестселлером в области бизнес-литературы.

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

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

Вот к последнему посту иллюстрация роста трафика в США от ИИ систем к продавцам.

Про новое SEO. Я еще для себя не определился, какой термин стоит использовать: GEO (Generative Engine Optimization), AEO (Answer Engine Optimization) или какой-то другой. Думаю, что в итоге закрепится только один вариант. Но сути это не меняет: под AI-запросы все равно придется проводить специальную работу по оптимизации, если хочется оставаться в поле видимости пользователей.

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

Новое исследование Omnisend показывает: пользователи, по крайней мере в США, все чаще обращаются к LLM для поиска и выбора товаров. И главное — находят этот процесс удобным. А это значит, что тренд будет только расширяться. По мере того как новые LLM-инструменты станут доступнее, они быстро охватят и другие страны.

В июле 2025 года Omnisend опросили 4000 взрослых из США, Великобритании, Канады и Австралии о том, как они используют ИИ при онлайн-покупках. Краткие выводы такие:

- около 50% онлайн-покупателей в каждой стране используют GenAI для e-commerce-задач хотя бы раз в месяц;
- каждый четвертый утверждает, что ChatGPT предлагает товары лучше, чем Google;
- около 27–29% отмечают, что AI делает процесс онлайн-шопинга менее утомительным.

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

Бояться пока нечего. Сейчас важно готовиться к новой реальности и выстраивать стратегию оптимизации и продвижения с учетом AI.

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

На первом — пульт, который можно открыть на мобильном.
На втором отображаются 3D объекты, которыми можно управлять с пульта.

Интерфейсы связаны через простой серверный API с синхронизацией каждые 100 миллисекунд. Этого достаточно, чтобы все выглядело плавно, без задержек.

Отрисовка через на Three.js. Простые фигуры строятся прямо в браузере. Уточка загружается из локального файла, а последний объект загружается по URL из внешнего источника.

Вот такой эксперимент за $1,75 на V0. Пока не придумал, как это может пригодиться, но мне нравится сама возможность создания простой мультиэкранности.

Это в продолжении прошлого поста, отвечая на комментарий Anton Korenyako в LinkedIn: “А как быстро у v0 получится реализовать трекбол на экране телефона?”

Задачка с трекболом оказалась с подвохом.

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

Но все решает формулировка задачи.

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

После нескольких экспериментов я уточнил постановку.

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

В итоге потратил 4 запроса на $0.45. И еще пару часов GPT пытаясь понять, как от начального решения перейти к работающему.

Результат можно попробовать самому https://v0-smartphone-trackball-ui.vercel.app/

Для тех, кто хочет улучшить производительность своих команд программистов, рекомендую видео с Nicole Forsgren автором нескольких книг и Senior Director of Developer Intelligence в Google «How to measure AI developer productivity in 2025».

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

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

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

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

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

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

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


Похоже, предел человека — это около четырех часов продуктивной работы в день. Это отсылка к большой работе Глории Марк (Gloria Mark), посвящённой изучению влияния цифровых технологий на внимание, многозадачность и рабочие процессы. Книга вышла и на русском языке: «Метавнимание. Как сохранять продуктивность и удерживать фокус в цифровой реальности».

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

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

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

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

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

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

Хорошую тему поднял Якоб Нильсен в статье “Slow AI: Designing User Control for Long Tasks”. Он рассуждает о пользовательском опыте при выполнении долгих задач, характерных для современных ИИ-систем.

Вот несколько идей из статьи, которые мне показались особенно интересными.

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

Такой “медленный ИИ” создает новые UX-проблемы: потерю контроля, снижение фокуса, риск сбоев. Это требует другого подхода к проектированию интерфейсов.

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

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

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

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

Хорошо, если большая задача разбивается на предсказуемые фрагменты продолжительностью 5–15 минут. Тогда ее проще восстанавливать при сбое и легче контролировать прогресс выполнения.

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

Когда пользователь возвращается к задаче после перерыва, система должна помочь ему быстро восстановить/вспомнить контекст задачи (context reboarding). Уведомления, письма и сообщения тоже стоит писать так, чтобы напоминать, о какой задаче идет речь.

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

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

К тендеру я готовил презентацию с разными подходами и предложениями по изменению дизайна сайта, которые должны были повлиять на поведения посетителей. Изменения были обоснованными, в базе были метрики и мы показывали ожидаемые изменения при внедрении тех или иных решений.
Но когда речь идет о проектах с MAU в 10–20 миллионов пользователей, нужны не только быстрые улучшения. Важно думать о решениях, которые обеспечат рост аудитории на горизонте в год-два. Только так можно оправдать инвестиции в редизайн.

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

Так родилась идея добавить на сайт онлайн-игры. Для меня это был очевидный ход, потому что пример New York Times давно показал, что это работает. Но, как оказалось, не все знакомы с их результатами.
Мини-игры у NYT расположены внизу главной страницы, они встроены в рассылки и доступны подписчикам. Они стали не только инструментом вовлечения, но и драйвером роста платных подписок.

Axios писал об этом в статье “Games are helping the New York Times thrive amid media chaos”. В 2023 году в игры NYT сыграли более 8 миллиардов раз, а это около 22 миллионов игр в день. И для издательства цель не в том, чтобы стать игровой компанией, а в том, чтобы добавить ценности помимо основного продукта и стать частью повседневной жизни пользователей.
Мое предложение не было самым коротким путем к росту аудитории, но, как мне кажется, это пример того, как можно взять уже работающую идею и адаптировать под себя. И пусть это требует затрат, но изменить поведение пользователей, не меняя само содержание предложения, почти невозможно.

Вот такая история на сегодня. Хорошего всем дня 🙂

Листал Artificial Intelligence Index Report 2025 и вдруг поймал себя на мысли, что роботизация — это ведь не просто замена людей машинами. Когда она приходит в одну отрасль, начинает меняться и все вокруг.

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

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

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

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

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

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

Что полезного я вынес на этой неделе?

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

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

Я использую внешнюю систему (сейчас это Grok), чтобы задавать вопросы по темам, которые хочу уточнить или в которых надо разобраться. Например, о том, как лучше синхронизировать работу двух систем через Websocket для удаленного управления в игре. Это помогает не засорять контекст V0 лишними рассуждениями. И, как мне кажется (тут нужно больше экспериментов), приводит к меньшему количеству ошибочных решение со стороны ИИ агента.

Рабочая версия игры доступна по адресу v0-mobile-game-development-orpin.vercel.app

Версия ролика на Ютубе https://youtu.be/rR25uMylTo4?si=q7IY9NCdzNy809Vn

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

Например, работа Тома ДеМарко (Tom DeMarco) и Тимоти Листера (Timothy Lister) «Peopleware: Productive Projects and Teams». Она основана на исследовании, которые авторы проводили с 1977 по 1987 год. Книга вызвала интерес, и после первого издания в 1987 году вышло второе в 1999, а потом третье в 2013. То есть идеи и подходы книги выдержали проверку временем и остаются актуальными. На русском языке книга вышла в 2005 году под названием «Человеческий фактор. Успешные проекты и команды».

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

62% «лучших» программистов отмечали, что у них было достаточно уединенное рабочее место, а среди «худших» так считали только 19%. 76% «худших» часто отвлекались без необходимости, но только 38% «лучших» попадали в такую же ситуацию.

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

В общем, опенспейсы — зло для программистов, если нужна эффективность. Книга ДеМарко и Листера отличная и рекомендую ее почитать. Ну и читать книги вообще полезно, а это вы и так знаете.

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

К 2033 году компания планирует создать сеть дата-центров, которые будут потреблять 250 гигаватт энергии. Для сравнения, если бы OpenAI уже сейчас имела такую мощность, она заняла бы седьмое место в мире по потреблению электроэнергии, опередив Францию, Южную Корею, Бразилию и Саудовскую Аравию. Индия сейчас потребляет как раз 250 250 гигаватт энергии.

Откуда возьмется эта энергия? Ядерная энергетика вряд ли подойдет, для выработки 250 ГВт потребуется около 250 новых реакторов. Их строительство обойдется в 12,5 триллиона долларов и потребуется от 15 лет на каждый объект.

Самый вероятный путь — это переход на солнечную и другие возобновляемые источники энергии. Они дешевле и быстрее внедряются. Уже сегодня в США по показателю LCOE (Levelized Cost of Electricity, учет полной стоимости энергии, включая строительство и эксплуатацию) солнечная генерация в полтора раза выгоднее газовой, вдвое дешевле угольной и втрое — атомной. И это даже без субсидий, которых, вероятно, больше не будет, но которые делают ее сейчас почти бесплатной.
Амбиции OpenAI многих впечатляют, кто-то сомневается, многие обсуждают.

Вот, например, статья Sam Altman Wants 250 Gigawatts of Power. Is That Possible? в The Information.