В новом Codex CLI v0.121.0 появилась команда /memories.

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

Зачем он, если есть AGENTS.md, project rules и skills?

А изюминка в том, что это адаптивный механизм, который сам подстраивается и пишет для себя правила, исходя из истории переписки с вами.

Codex начинает собирать повторяющиеся паттерны и предпочтения по ходу работы.

Например:

- особенности вашего workflow
- детали проекта
- повторяющиеся требования
- вещи, которые раньше приходилось объяснять заново

В итоге меньше повторных объяснений и меньше ручного контекста в новых сессиях.

https://www.npmjs.com/package/@openai/codex/

Документация по /memories: https://developers.openai.com/codex/memories

Вышел новый Storybook 10.4

1. Automated setup ⚙️

Storybook теперь можно настраивать через AI-агента.
Он может сам создать конфиг, добавить моки, написать stories и interaction tests, проверить рендер компонентов и доработать настройку, пока проект не заведётся.

Главная польза: меньше ручной настройки на старте.

2. Change detection 👀

-В сайдбаре появились фильтры New, Modified и Related.

Они показывают:

- новые stories;
- изменённые stories;
- stories, которые могли быть затронуты изменениями в коде.

Почему это удобно: для UI-ревью не нужно смотреть весь Storybook. Можно сразу открыть то, что реально изменилось или могло сломаться.

3. Quick sharing 🔗

Теперь можно быстро поделиться конкретной story, над которой работаешь.

Story — это отдельное состояние компонента: форма с ошибкой, открытая модалка, loading-состояние, кнопка в нужном варианте.

Главное: не нужен commit, PR или ожидание CI. Открыл нужную story, отправил ссылку, получил обратную связь.

4. TanStack React framework 🧩

Добавили поддержку React-проектов на TanStack через @storybook/tanstack-react.

TanStack — это набор инструментов для React: роутинг, работа с серверными данными, server functions и React Query.

Если проект использует TanStack Router, TanStack Start или React Query, Storybook теперь проще подключить и настроить.

5. React Native setup and isolation 📱

Этот пункт относится только к проектам на React Native.

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

STORYBOOK_ENABLED=true — это технический переключатель именно для React Native-проектов. Для обычных web-проектов на React или Vue это не актуально.

6. React Component Meta for MCP 🚀

Добавили экспериментальный react-component-meta.

Он анализирует React-компоненты: props, типы, описания и API компонента.

Главное преимущество: скорость. В примерах из статьи новый анализатор работает в десятки раз быстрее старого react-docgen-typescript.

За счёт этого Storybook быстрее понимает структуру компонентов, а AI-инструменты быстрее получают нужный контекст.

Сегодня в очередной раз сталкиваясь с проблемами Windows / Docker / WSL вернулся к теме настройки рабочего места.
Если у вас есть уже готовые конфигурации сервисов, то намного удобнее использовать именно их, и docker compose тут очень удобен.

Однако что делать, если вашему процессу Docker надо работать с файлами в файловой системы Windows?
Если вы давно пользуетесь WSL или вообще не являетесь пользователем Windows, то о такой проблеме вы даже не слышали.

Проблема проста: Docker работает в WSL, и если ваш проект находится в Windows (например на диске c:/), то процессы докер при работе с файлами будут тормозить.

Прыгать между окружениями Windows / WSL не удобно, и поэтому использовать WSL не хочется. Тем более, что IDE и другие программы хорошо работают с файловой системой Windows, а попытки их подружить с WSL очередной раз отвлекают от основных задач при работе с проектом.

Кроме этого синтаксис PowerShell я не знаю, переходить на него не хочется, и это для меня не удобно. Но и WSL со своими ограничениями не особ приятен.
Поэтому на Windows использую Git Bash, и этого почти всегда достаточно. Хотя это и менее удобно чем стандартные команды Ubuntu.
Вместе с этим продолжаю искать решения, как поднять необходимые сервисы с минимальными усилиями, которые уже настроены в Docker compose, но которые я не могу использовать с удобством в Windows.

Чтобы быстро тестировать различные варианты интеграций, я написал небольшой тест для проверки скорости работы в Windows / Docker / WSL. ⚙️

Ссылка на этот тест: https://github.com/Artemeey/bench-runtime-windows-vs-wsl/blob/main/README.ru.md#%D0%B1%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9-%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B9-%D1%82%D0%B5%D1%81%D1%82

Для запуска достаточно выполнить команду, указанную в документации, в нужной папке в Windows / Docker / WSL.

Результаты шокируют: чтение файлов из Docker в папке C:/ медленнее в 40 раз, а механизм кеширования файловой системы ext4 в WSL при повторных обращениях к файлам приводит к ускорению в 10 раз по сравнению с обычной работой в файловой системе Windows. ⚡️

Полный бенчмарк со сравнением работы с файлами в Windows / WSL: https://github.com/Artemeey/bench-runtime-windows-vs-wsl

💡Полезные советы: исправляем Unicode в Windows Git Bash

По умолчанию в Git Bash обычно используется UTF-8, и Unicode работает корректно. Однако переменная окружения LANG может быть не задана. Из-за этого после ввода текста на кириллице в консоли может ломаться последующий ввод.

Пример:
* пишем ды
* стираем ды
* пишем ls
* в выводе получаем: bash: □□ls: command not found

Для решения проверьте локаль:

locale

Если значение LANG не задано, установите его вручную:

export LANG=C.UTF-8

Повторите проверку. Если помогло, сохраните настройку в ~/.bashrc:

printf 'export LANG=C.UTF-8\n' >> ~/.bashrc

Проверить содержимое пользовательских настроек Git Bash можно так:

cat ~/.bashrc

Карманный ПК переизобретен с ИИ-агентом 💻✨

Что это значит?
Сейчас расскажу.

Сегодня ездил загород и первый раз провел рабочий день (вернее отдых) с доступом к коду на телефоне 📱, решая рабочие задачи. Пишу задачи ИИ, он начинает работу на домашнем ПК. Раз в 15 минут захожу в телефон и контролирую процесс ⏱️.

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

И отдохнул, и сделал полезные дела, на которые раньше пришлось бы провести у компа много времени 🤖🌳.

В Safari 27 Beta была исправлена проблема с загрузкой модулей JS! 🚀

Удивительно слышать в 2026 году, что до сих пор Safari оставался почти единственным браузером, где ESM не работал (или, скорее, почти работал). 🤔

С этого момента ESM приближается к продакшену, и среда разработки становится возможной в Safari (или, точнее, Safari становится более доступным для разработки) 💻✨

Safari уже формально поддерживал top-level await, но были баги в сложных графах ES-модулей: порядок выполнения модулей и инициализация экспортов могли работать некорректно. В Safari 27 Apple/WebKit переписали загрузчик ES-модулей и исправили проблемы совместимости с top-level await 🛠️

https://bugs.webkit.org/show_bug.cgi?id=242740 🔗

Дополнительное полезное обновление в Safari 27 beta 📱

Вскоре в паре с лениво загружаемыми изображениями можно будет использовать в продакшене sizes=\"auto\" 💻.

В Safari 27 beta появилась поддержка sizes=\"auto\". Теперь браузер может самостоятельно определить фактическую ширину изображения в макете и выбрать подходящий файл из srcset без ручного расчета значения sizes.

После релиза Safari 27 все основные браузеры будут поддерживать эту функцию.

Как было раньше:

<img
  src="card-800.jpg"
  srcset="card-400.jpg 400w, card-800.jpg 800w, card-1200.jpg 1200w"
  sizes="(max-width: 768px) 100vw, 33vw"
  loading="lazy"
  width="1200"
  height="800"
  alt=""
>

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

Теперь для лениво загружаемых изображений можно использовать sizes="auto":

<img
  src="card-800.jpg"
  srcset="card-400.jpg 400w, card-800.jpg 800w, card-1200.jpg 1200w"
  sizes="auto, 100vw"
  loading="lazy"
  width="1200"
  height="800"
  alt=""
>

В этом случае браузер может опираться на фактическую ширину изображения в макете и сам выбрать подходящий ресурс из srcset.
Запасное значение после auto нужно для браузеров, которые не поддерживают этот режим. Например, в sizes="auto, 100vw" современные браузеры смогут использовать auto, а остальные обработают запасное значение 100vw.

Где это особенно полезно
sizes="auto" хорошо подходит для изображений, которые находятся ниже первого экрана и загружаются лениво:
- карточки товаров;
- изображения в списках;
- галереи;
- превью статей;
- адаптивные сетки;
- блоки, ширина которых сильно зависит от контейнера.