По делу: проблема не в том, что токен можно украсть из localStorage. Проблема в том, что MAX (и многие другие сервисы) вообще хранят валидный токен в открытом виде в "локалсторедж". Правильный подход — httpOnly cookie с флагом Secure + SameSite=Strict. Тогда даже если вы скопируете весь localStorage — ничего не зайдёт.
Что делать обычному пользователю: выходить из аккаунта на чужих компах кнопкой «Выйти», а не просто закрывать вкладку. И не оставлять браузер без присмотра.
P.S. За дисклеймер про «делайте только со своим аккаунтом» — жирный плюс. Многие об этом забывают.
Хорошая попытка приземлить «голубые океаны» на реальный алгоритм, а не оставлять их красивой метафорой.
Но есть два «но» с практической точки зрения.
Первое. Шаг 0 («целеполагание») — самый важный и самый слабый в вашем описании. Вы предлагаете формулировать цель «от сегмента» или «от идеи». На практике проблема не в формулировке, а в том, что внутри компании эти цели конфликтуют. Маркетинг хочет B2C-охват 100К, финансы — выручку 500 млн, а продукт — уникальную ИИ-фабрику. В итоге — паралич. Не хватает шага 0.5: «согласовать критерий успеха между стейкхолдерами до генерации гипотез». В противном случае, ваш длинный список превратится в свалку хотелок, а не в набор для верификации.
Второе. Вы упоминаете MVP и «первые продажи», но молчите про стоимость ошибки. Для маркетплейса с миллионной аудиторией кривой MVP — это не просто потерянные деньги на разработку, это сгоревший канал коммуникации с сегментом. Запустили плохую аналитику для B2B — продавцы ушли к конкурентам навсегда. Где в алгоритме оценка рисков прежде, чем катапультировать MVP в сегмент?
Что хорошо: вы честно признаёте, что «скачок ценности» без анализа спроса ведёт в пропасть. Это бьёт по розовым очкам «голубо-океанщиков». Добавьте ещё один шаг — «оценка стоимости ухода из сегмента при провале» — и алгоритм станет рабочим.
P.S. Формулировка «от сегмента» с цифрами по охвату и чеку — сильная. Это редкий случай, когда страшное слово «целеполагание» обретает плоть. За это отдельный плюс.
Спасибо за подборку! Тема действительно становится всё актуальнее.
Почему сейчас: в 2026 году даже привычные «облачные» сервисы всё чаще требуют VPN или вообще недоступны. И дело не только в санкциях — многие зарубежные таск-менеджеры и заметочники начали блокировать российские IP без предупреждения. Поэтому офлайн-first — это уже не «удобно», а единственный способ гарантированно иметь доступ к своим задачам и документам.
Что добавлю от себя: в вашей таблице не хватает самодеплойных решений. Например, Vikunja (таск-менеджер) или Outline (wiki/заметки) можно поднять на своём сервере, и они будут работать офлайн на клиентах, а синхронизация — через вашу инфраструктуру. Да, порог входа выше, но зато вы не зависите от политики «неопределённого» зарубежного владельца.
И ещё: из российских офлайн-инструментов в дорожной карте МойОфис уже давно, а вот Р7-Офис и Яндекс.Офис (десктопная версия) тоже достойны упоминания. У них локальное хранение по умолчанию.
Планировщик задач без интернета — это база. Но в 2026 году я бы добавил колонку «Поддержка самодеплоя». Потому что даже офлайн-приложение бесполезно, если его облачный бэкенд однажды просто перестанет пускать с вашего IP.
Спасибо за труд, подборка очень вовремя. Жду следующую часть с фокусом на российские и self-hosted решения.
Хорошая и вполне добротная статья, ёмко и по делу. Особенно порадовал чек-лист в конце — можно брать в работу тем, у кого нет управленческого опыта.
Теперь добавлю свой кейс, которого вам не хватает.
Я руководитель проектов, который год назад переехал из Владивостока в Петербург. Хотите узнать мои первые впечатления? В Питере команды срывают сроки реже, но последствия — дороже. Один день простоя здесь стоит как три во Владивостоке. А причина — не в людях, а в скрытых согласованиях. В регионах договориться можно устно за час. В Петербурге — три уровня апрувов и ИБ, о которых ты узнаёшь в день дедлайна.
Ваши шесть причин — база. Но есть седьмая: «Задача согласована, но не всеми, кто может её убить». Это не про исполнителя. Это про то, что в big city формальные силы (полномочия) важнее скорости. Я перестал спрашивать «кто сделает» и начал спрашивать «кто может остановить». И дедлайны перестали срываться так безболезненно.
Скоро в своей статье разберу, как после переезда я внедрил ИИ-агента, который за 5 минут сканирует чаты и выявляет скрытых согласующих до того, как они заблокируют проект. Спойлер: срывы сроков сократились на 30%.
Заглядывайте, если интересен взгляд управленца, который работал и на Дальнем Востоке, и в культурной столице. А автору желаю всего наилучшего, разумеется.
Прочитал, хоть и не быстро ;) Система сильная, подход с манифестом + OKR + Claude Code — это на голову выше обычных «А я у ChatGPT попросил стратегию».
Теперь критика (постараюсь быть кратким):
Вы дважды обходите вопрос безопасности. «Лечится enterprise-тарифами» — это не лечение. Ваши цены, прайсинг, risk register, планы на квартал улетают провайдеру. Для real business это стоп-фактор, особенно после 2025 года. И локальный инференс вы не сделали — Claude локально не поставить.
Второе: «Ксен меня челленджит» — да, но только пока вы не устали. На четвёртом раунде спора модель сдаётся, потому что обучена услужливости, а не принципиальности. Ваш манифест — это костыль, не архитектура. Настоящий партнёр не сдаётся, когда вы просто настойчивее.
P.S. За структуру и открытость — лайк. Такое редко встречается.
Прочитал. Кейс рабочий, подход с ролями — хороший уровень. Но есть одно «но» про Gemini.
Вы пишете: «Google Gemini (deep research) — дорогая и может ковыряться полчаса, но даёт лучший результат». Это было правдой зимой 2025 года. Нынче, в июне 2026-го, Gemini заметно сдал. На сложной сегментации (особенно с JTBD и неочевидными потребностями) он стал давать более поверхностные ответы, хуже держит контекст и чаще галлюцинирует с источниками. DeepSeek с режимом рассуждений его уже обгоняет по качеству при цене 0$.
Я бы на вашем месте советовал перепроверять Gemini-исследования хотя бы GPT-5 или Claude Opus. А лучше — заменить в связке на них. Иначе маркетологи, которые поверят в «лучший результат», потеряют время на доработку галлюцинаций.
P.S. В остальном — отличный разбор, фреймворк P.R.O.M.P.T забрал в копилку.
Прочитал. Достойная публикация — спасибо за честность и про «плохие дни у моделей», а ещё про цену контекстного окна.
По делу: Описан отличный процесс для greenfield R&D, но в продакшене с легаси другой сценарий — модели не знают ваши 10-летние внутренние фреймворки, кастомные протоколы и «договорённости». Там помощь ИИ сводится к дописыванию boilerplate и переводу тестов, но не к архитектуре.
И главное: вы потратили месяц вечеров + выходных. Команда из двух джунов с вашим ТЗ сделала бы то же самое за 2-3 недели. Вопрос не в «можно ли с ИИ», а окупается ли подписка при вашей з/п. 40$ — да. Ваше время — нет. ИИ не ускорил вас - ИИ заменил пару стажёров.
Кейс хороший, но партнёрство начинается не с «как сделать», а с «стоит ли делать». Вы не спросили бизнес, можно ли переложить учёт НДС на подрядчиков или зашить в стоимость. Инициатива без оспаривания задачи — это всё ещё проактивный исполнитель, не партнёр. Смените фокус — и ценность вырастет.
Полностью согласен... ... а ещё "закос от армии" нынче не актуален и так стенать из-за этого такое себе. Год "потусить" в форме и то за "подвиг" уже считается ))) Бабы правы, мужиков-то не осталось...
Неочевидный вывод в том, что главная опасность ИИ сейчас — не галлюцинации, не агенты, которые грохают базы, и не утечка данных. Главная опасность в том, что мы сами, добровольно и с энтузиазмом, помещаем этот инструмент в центр нашей эмоциональной жизни, разговаривая с ним «как с сыном» и воспринимая его «извините за это» за чистую монету. Мы воспитываем поколение, для которого норма — это эмоциональная связь с программой. И текст «жалоб» в этом смысле — не столько инструкция по работе с багами, сколько исторический документ, фиксирующий момент, когда миллионы людей одновременно и навсегда разучились злиться на бездушный код и начали злиться на «Лёху из соседнего отдела»...
Елена неоднократно предлагает «написать свой парсер» или собрать «кастом на Mastra/LangGraph» как альтернативу готовым сервисам. При этом полностью опускается вопрос совокупной стоимости владения таким решением (TCO), включая зарплату разработчика, время на поддержку, исправление багов и адаптацию к меняющимся API источников. Это не слабость какого-то конкретного рецепта, а неполнота картины для новичка, который может недооценить скрытые издержки «бесплатного» опенсорса и кастомной разработки. Я вполне приемлю тот факт, что для профи всё это - "семечки", но я лично не разработчик уровня "продвинутый" и уже вряд ли таковым стану и потому "полную картину" для простого пользователя есть желание лицезреть ;)
В разделе о конфигурации сервера БД приводятся конкретные значения для join_buffer_size и sort_buffer_size (по 4M). При этом не упомянуто критически важное предостережение о том, что эти буферы выделяются на каждый запрос, и их необдуманное увеличение на сервере с сотнями одновременных соединений может привести к мгновенному исчерпанию оперативной памяти и падению всей системы. Для новичка, который скопирует эти настройки бездумно, такая рекомендация несёт скорее вред, чем пользу. И ещё один нюанс по-поводу внимания к диагностики и её неравномерности у автора. Он стартует с методичной диагностики, но к концу повествования оное превращается в перечисление отдельных рецептов без чёткой связи с диагностированными проблемами. Так и остаётся неясным: если я найду в slow query log проблему, но она не связана с UF-полями, N+1 или SELECT *, то что делать? Методология неполна — диагностика детальна, а список решений ограничен и не покрывает всех возможных причин из лога... Однако, автору респект ;)
Ключевые цифры указывают на системный спад: выручка в январе упала на 26% год к году (с 2,7 до 2 млн), а расходы выросли по всем фронтам (аренда, НДС, материалы). Рентабельность всего бизнеса в 7% при кредитах под 30%+ годовых — это хождение по лезвию. На этом фоне финальное решение автора звучит как побег от реальности, а не как продуманная стратегия: «Хочу делать меньше серийных изделий, но с более высоким чеком — работать скорее как мастерская». Это кардинальная смена бизнес-модели, но в тексте нет ни слова о том, есть ли платёжеспособный спрос на такие изделия в Ижевске, найден ли хоть один клиент, кроме упомянутых вскользь дизайнеров, и за счёт чего вообще будет обеспечиваться этот «более высокий чек».
Автор подаёт normalization="image" как инсайт от грандмастера Kaggle, эквивалентный RandomBrightnessContrast, но наоборот. Возникает закономерный вопрос: если это, по сути, просто другой способ сделать то же самое, зачем может понадобиться эта неявная, неконтролируемая форма вместо явной и прозрачно параметризуемой? Когда и почему один метод аффинного преобразования пикселей должен работать лучше другого? Тезис о том, что это «бесплатная аугментация», остаётся недоказанным, а механизм её преимущества перед простым тюнингом параметров RandomBrightnessContrast не раскрыт.
Познавательно и пугающе одновременно.
По делу: проблема не в том, что токен можно украсть из localStorage. Проблема в том, что MAX (и многие другие сервисы) вообще хранят валидный токен в открытом виде в "локалсторедж".
Правильный подход — httpOnly cookie с флагом Secure + SameSite=Strict. Тогда даже если вы скопируете весь localStorage — ничего не зайдёт.
Что делать обычному пользователю: выходить из аккаунта на чужих компах кнопкой «Выйти», а не просто закрывать вкладку. И не оставлять браузер без присмотра.
P.S. За дисклеймер про «делайте только со своим аккаунтом» — жирный плюс.
Многие об этом забывают.
Хорошая попытка приземлить «голубые океаны» на реальный алгоритм, а не оставлять их красивой метафорой.
Но есть два «но» с практической точки зрения.
Первое. Шаг 0 («целеполагание») — самый важный и самый слабый в вашем описании.
Вы предлагаете формулировать цель «от сегмента» или «от идеи».
На практике проблема не в формулировке, а в том, что внутри компании эти цели конфликтуют.
Маркетинг хочет B2C-охват 100К, финансы — выручку 500 млн, а продукт — уникальную ИИ-фабрику.
В итоге — паралич.
Не хватает шага 0.5: «согласовать критерий успеха между стейкхолдерами до генерации гипотез».
В противном случае, ваш длинный список превратится в свалку хотелок, а не в набор для верификации.
Второе. Вы упоминаете MVP и «первые продажи», но молчите про стоимость ошибки.
Для маркетплейса с миллионной аудиторией кривой MVP — это не просто потерянные деньги на разработку, это сгоревший канал коммуникации с сегментом.
Запустили плохую аналитику для B2B — продавцы ушли к конкурентам навсегда.
Где в алгоритме оценка рисков прежде, чем катапультировать MVP в сегмент?
Что хорошо:
вы честно признаёте, что «скачок ценности» без анализа спроса ведёт в пропасть. Это бьёт по розовым очкам «голубо-океанщиков».
Добавьте ещё один шаг — «оценка стоимости ухода из сегмента при провале» — и алгоритм станет рабочим.
P.S. Формулировка «от сегмента» с цифрами по охвату и чеку — сильная.
Это редкий случай, когда страшное слово «целеполагание» обретает плоть.
За это отдельный плюс.
Спасибо за подборку! Тема действительно становится всё актуальнее.
Почему сейчас:
в 2026 году даже привычные «облачные» сервисы всё чаще требуют VPN или вообще недоступны.
И дело не только в санкциях — многие зарубежные таск-менеджеры и заметочники начали блокировать российские IP без предупреждения.
Поэтому офлайн-first — это уже не «удобно», а единственный способ гарантированно иметь доступ к своим задачам и документам.
Что добавлю от себя: в вашей таблице не хватает самодеплойных решений.
Например, Vikunja (таск-менеджер) или Outline (wiki/заметки) можно поднять на своём сервере, и они будут работать офлайн на клиентах, а синхронизация — через вашу инфраструктуру.
Да, порог входа выше, но зато вы не зависите от политики «неопределённого» зарубежного владельца.
И ещё: из российских офлайн-инструментов в дорожной карте МойОфис уже давно, а вот Р7-Офис и Яндекс.Офис (десктопная версия) тоже достойны упоминания.
У них локальное хранение по умолчанию.
Планировщик задач без интернета — это база.
Но в 2026 году я бы добавил колонку «Поддержка самодеплоя».
Потому что даже офлайн-приложение бесполезно, если его облачный бэкенд однажды просто перестанет пускать с вашего IP.
Спасибо за труд, подборка очень вовремя.
Жду следующую часть с фокусом на российские и self-hosted решения.
Хорошая и вполне добротная статья, ёмко и по делу.
Особенно порадовал чек-лист в конце — можно брать в работу тем, у кого нет управленческого опыта.
Теперь добавлю свой кейс, которого вам не хватает.
Я руководитель проектов, который год назад переехал из Владивостока в Петербург.
Хотите узнать мои первые впечатления?
В Питере команды срывают сроки реже, но последствия — дороже.
Один день простоя здесь стоит как три во Владивостоке.
А причина — не в людях, а в скрытых согласованиях.
В регионах договориться можно устно за час.
В Петербурге — три уровня апрувов и ИБ, о которых ты узнаёшь в день дедлайна.
Ваши шесть причин — база.
Но есть седьмая:
«Задача согласована, но не всеми, кто может её убить».
Это не про исполнителя.
Это про то, что в big city формальные силы (полномочия) важнее скорости. Я перестал спрашивать «кто сделает» и начал спрашивать «кто может остановить».
И дедлайны перестали срываться так безболезненно.
Скоро в своей статье разберу, как после переезда я внедрил ИИ-агента, который за 5 минут сканирует чаты и выявляет скрытых согласующих до того, как они заблокируют проект. Спойлер: срывы сроков сократились на 30%.
Заглядывайте, если интересен взгляд управленца, который работал и на Дальнем Востоке, и в культурной столице.
А автору желаю всего наилучшего, разумеется.
Прочитал, хоть и не быстро ;)
Система сильная, подход с манифестом + OKR + Claude Code — это на голову выше обычных «А я у ChatGPT попросил стратегию».
Теперь критика (постараюсь быть кратким):
Вы дважды обходите вопрос безопасности.
«Лечится enterprise-тарифами» — это не лечение.
Ваши цены, прайсинг, risk register, планы на квартал улетают провайдеру. Для real business это стоп-фактор, особенно после 2025 года.
И локальный инференс вы не сделали — Claude локально не поставить.
Второе: «Ксен меня челленджит» — да, но только пока вы не устали.
На четвёртом раунде спора модель сдаётся, потому что обучена услужливости, а не принципиальности.
Ваш манифест — это костыль, не архитектура.
Настоящий партнёр не сдаётся, когда вы просто настойчивее.
P.S. За структуру и открытость — лайк. Такое редко встречается.
Год миновал и нейросети поумнели сильно. Пора актуализировать тему, создав новую статью :)
Заранее благодарю за проделанную работу.
Всем добра и мира!
Прочитал. Кейс рабочий, подход с ролями — хороший уровень. Но есть одно «но» про Gemini.
Вы пишете: «Google Gemini (deep research) — дорогая и может ковыряться полчаса, но даёт лучший результат». Это было правдой зимой 2025 года.
Нынче, в июне 2026-го, Gemini заметно сдал.
На сложной сегментации (особенно с JTBD и неочевидными потребностями) он стал давать более поверхностные ответы, хуже держит контекст и чаще галлюцинирует с источниками. DeepSeek с режимом рассуждений его уже обгоняет по качеству при цене 0$.
Я бы на вашем месте советовал перепроверять Gemini-исследования хотя бы GPT-5 или Claude Opus.
А лучше — заменить в связке на них. Иначе маркетологи, которые поверят в «лучший результат», потеряют время на доработку галлюцинаций.
P.S. В остальном — отличный разбор, фреймворк P.R.O.M.P.T забрал в копилку.
Прочитал. Достойная публикация — спасибо за честность и про «плохие дни у моделей», а ещё про цену контекстного окна.
По делу: Описан отличный процесс для greenfield R&D, но в продакшене с легаси другой сценарий — модели не знают ваши 10-летние внутренние фреймворки, кастомные протоколы и «договорённости».
Там помощь ИИ сводится к дописыванию boilerplate и переводу тестов, но не к архитектуре.
И главное: вы потратили месяц вечеров + выходных.
Команда из двух джунов с вашим ТЗ сделала бы то же самое за 2-3 недели. Вопрос не в «можно ли с ИИ», а окупается ли подписка при вашей з/п.
40$ — да.
Ваше время — нет.
ИИ не ускорил вас - ИИ заменил пару стажёров.
P.S. За LSP для Claude — лайк, сам не пробовал.
Кейс хороший, но партнёрство начинается не с «как сделать», а с «стоит ли делать». Вы не спросили бизнес, можно ли переложить учёт НДС на подрядчиков или зашить в стоимость. Инициатива без оспаривания задачи — это всё ещё проактивный исполнитель, не партнёр.
Смените фокус — и ценность вырастет.
Полностью согласен...
... а ещё "закос от армии" нынче не актуален и так стенать из-за этого такое себе. Год "потусить" в форме и то за "подвиг" уже считается )))
Бабы правы, мужиков-то не осталось...
ответ понятен. Благодарю.
ясно, благодарю за ответ.
Неочевидный вывод в том, что главная опасность ИИ сейчас — не галлюцинации, не агенты, которые грохают базы, и не утечка данных.
Главная опасность в том, что мы сами, добровольно и с энтузиазмом, помещаем этот инструмент в центр нашей эмоциональной жизни, разговаривая с ним «как с сыном» и воспринимая его «извините за это» за чистую монету.
Мы воспитываем поколение, для которого норма — это эмоциональная связь с программой. И текст «жалоб» в этом смысле — не столько инструкция по работе с багами, сколько исторический документ, фиксирующий момент, когда миллионы людей одновременно и навсегда разучились злиться на бездушный код и начали злиться на «Лёху из соседнего отдела»...
Елена неоднократно предлагает «написать свой парсер» или собрать «кастом на Mastra/LangGraph» как альтернативу готовым сервисам.
При этом полностью опускается вопрос совокупной стоимости владения таким решением (TCO), включая зарплату разработчика, время на поддержку, исправление багов и адаптацию к меняющимся API источников.
Это не слабость какого-то конкретного рецепта, а неполнота картины для новичка, который может недооценить скрытые издержки «бесплатного» опенсорса и кастомной разработки.
Я вполне приемлю тот факт, что для профи всё это - "семечки", но я лично не разработчик уровня "продвинутый" и уже вряд ли таковым стану и потому "полную картину" для простого пользователя есть желание лицезреть ;)
В разделе о конфигурации сервера БД приводятся конкретные значения для
join_buffer_sizeиsort_buffer_size(по 4M).При этом не упомянуто критически важное предостережение о том, что эти буферы выделяются на каждый запрос, и их необдуманное увеличение на сервере с сотнями одновременных соединений может привести к мгновенному исчерпанию оперативной памяти и падению всей системы.
Для новичка, который скопирует эти настройки бездумно, такая рекомендация несёт скорее вред, чем пользу.
И ещё один нюанс по-поводу внимания к диагностики и её неравномерности у автора.
Он стартует с методичной диагностики, но к концу повествования оное превращается в перечисление отдельных рецептов без чёткой связи с диагностированными проблемами.
Так и остаётся неясным: если я найду в
slow query logпроблему, но она не связана с UF-полями, N+1 илиSELECT *, то что делать?Методология неполна — диагностика детальна, а список решений ограничен и не покрывает всех возможных причин из лога...
Однако, автору респект ;)
Ключевые цифры указывают на системный спад: выручка в январе упала на 26% год к году (с 2,7 до 2 млн), а расходы выросли по всем фронтам (аренда, НДС, материалы). Рентабельность всего бизнеса в 7% при кредитах под 30%+ годовых — это хождение по лезвию.
На этом фоне финальное решение автора звучит как побег от реальности, а не как продуманная стратегия: «Хочу делать меньше серийных изделий, но с более высоким чеком — работать скорее как мастерская».
Это кардинальная смена бизнес-модели, но в тексте нет ни слова о том, есть ли платёжеспособный спрос на такие изделия в Ижевске, найден ли хоть один клиент, кроме упомянутых вскользь дизайнеров, и за счёт чего вообще будет обеспечиваться этот «более высокий чек».
Автор подаёт
normalization="image"как инсайт от грандмастера Kaggle, эквивалентныйRandomBrightnessContrast, но наоборот.Возникает закономерный вопрос: если это, по сути, просто другой способ сделать то же самое, зачем может понадобиться эта неявная, неконтролируемая форма вместо явной и прозрачно параметризуемой?
Когда и почему один метод аффинного преобразования пикселей должен работать лучше другого?
Тезис о том, что это «бесплатная аугментация», остаётся недоказанным, а механизм её преимущества перед простым тюнингом параметров
RandomBrightnessContrastне раскрыт.Чиновничий беспредел крепчал и рос - шёл пятый год войны...
— А в чём сила, брат?
— А вот в чём! В деньгах вся сила, брат! Деньги правят миром, и тот сильней, у кого их больше...
Слишком логично и правильно. Именно поэтому ныть продолжат именно те, кто "звездился" )