У ИТ-шников распространено ощущение, что все остальные профессии могут закрываться ИИ без ревью, нужно сделать бренд - сгенерируем брендбук, договор оферты - да пожалуйста аишка сделает, дизайн нарисовать - вообще просто, юзабилити для UI, по бизнесу не нужно ничего специально знать, нас нужны роли CEO, CMO, CFO - да что они вообще делают, просто на звонках висят, их нам вообще не нужно. И только у некоторых возникает смутное ощущение, что что-то тут не так, если ИИ может нагенерить мне лапшу в коде, то и бизнес-план без ревью будет не очень... И вот только на этапе продаж выясняется, что этот софт никому не нужен, абыдна, да? Но на самом деле, даже архитектуру системы программист делает обычно лишь бы как, например, идея "переписать с нуля при работающем бизнесе" не вызывает у программистов резкого осуждения и даже "кодить без ТЗ" это норм, мы ж как-бы сами не идиоты, знаем что делаем... Только вот заканчивается это быстро, месяцев 3-6, потом нет энтузиазма, заморозка и через год только себе признаются, это в лучшем случае.

В этот четверг на созвоне сообщества Метархия обсудим

Стартап инкубатор Meta Qube

Основные его идеи:
- с AI стало возможно делать стартапы малыми силами и вложениями
- ИТшники до уровня синьора не могут найти работу, решение - стартап
- начинающим негде получить первый опыт, решение - стартап
- синьоры и архитекторы сейчас часто предпочитают сделать свой продукт вместо того, чтоб работать на дядю
- инвесторы хотели бы заработать на AI буме, но нет доверия, везде нейрослоп
- 80% функций любого стартапа одинаковые и писать их каждый раз заново нет смысла: платежи, API, лендинг, рассылка, боты, и многое другое
- универсальный модуль для переиспользования сделать всего на 20-30% сложнее, вынеся конфиги и метаданные, использую DSL и схемы
- переиспользуемая модуль будет гораздо качественнее, чем навайбкоженный и проще обеспечить его поддержку и улучшение

🎙️ Metarhia community call
Thursday, Jul 2  •  19:00 – 21:00
Google Meet joining info
Video call link: ссылка опубликована для Patreon подписчиков
https://www.patreon.com/c/tshemsedinov

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

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

Что нового в материалах
- Записи всех предыдущих тем (см. на сайте)
- Новые лекции и стримы об архитектуре от Тимура
- Новые лекции и стримы о коммуникации от Ильи
- Курс по TypeScript от Ильи
- Много материалов про AI

Заходим, не стесняемся https://nexttick.it/?utm_source=timur_tg_howprogworks

По многочисленным заявкам у нас будут сессии лайвкода, с разработкой архитектуры, применением AI, ревью кода и при помощи тех техник, которые мы пропагандируем (хорошее описание, md файлики со спеками и ADR, и все такое), сегодня сразу две сессии такие, доменный код и системный код:

🧑‍💻 Livecoding + AI: Payment Gateway (Тимур и Нечай)
Платежная система - доменный код и архитектура
Thursday, 9 July · 17:00 – 19:00 Time zone: Europe/Kiev
В NextTick https://nexttick.it/?utm_source=timur_tg_howprogworks

🎙 Metarhia: metautil, metacom, data structures (Тимур)
Системный и платформенный код и архитектура
Thursday, 9 July · 19:00 – 21:00 Time zone: Europe/Kiev
В сообществе Метархия https://www.patreon.com/c/tshemsedinov

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

Ладно там Fable, а вы такое умели?

Через объект-контейнер и свойство с динамическим именем

const createClass = (name) => {
  const container = { [name]: class {} };
  const Entity = container[name];
  return Entity;
};

Более короткий способ

const createClass = (name) => ({
  [name]: class {},
})[name];

Или через деструктуризацию

const createClass = (name) => {
  const { [name]: Entity } = { [name]: class {} };
  return Entity;
};

И еще про оптимизации в V8
(статья с блога v8, она актуальна по состоянию на 2026)

👉 https://v8.dev/blog/pointer-compression

- Большая часть памяти V8 хранит указатели и небольшие значения (SMI)
- SMI означает Small Integer, то есть небольшое целое число
- SMI хранится прямо в ячейке значения без создания отдельного объекта в куче
- Сжатый указатель хранит небольшое смещение адреса вместо полного 64-битного адреса
- Один изолят V8 должен хранить свою кучу в области памяти размером до 4 ГБ
- Сжатые указатели и SMI занимают 32 бита в памяти
- V8 разворачивает указатели при чтении и сжимает их при сохранении
- V8 хранит базовый адрес кучи в регистре CPU для быстрого разворачивания указателей
- Сжатие указателей уменьшает диапазон целых чисел SMI и ограничивает прямое значения double
- Это может уменьшить размер кучи V8 до 43%, а использование памяти процессом рендеринга браузера до 20%

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

Первый контур: технологический стек

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

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

Это крупные готовые возможности: аутентификация, платежи, уведомления, workflow, отчёты, интеграции, роли и права, биллинг, отчеты и т.д. Здесь используются метапрограммирование, кодогенерация, схемы, зависимые типы, декларативные контракты и динамическая диспетчеризация. Модуль не реализует один конкретный сценарий. Он представляет семейство сценариев и перенастраивается через метаданные, политики, схемы и обработчики. Второй контур уменьшает кодовую базу третьего на несколько порядков.

Третий контур: продукт

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

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

Эти и другие вопросы обсуждаем каждый четверг на созвоне сообщества https://www.patreon.com/c/tshemsedinov

Object.freeze / seal / preventExtensions: сколько это стоит в V8

Бенчмарк на create / read / write для обычного объекта {} и трех режимов защиты: freeze, preventExtensions, seal.

- create: защита дороже обычного объекта ~в x4: {} 5.7 ns, а для freeze/seal ~25 ns
- read: разницы почти нет, все ~1.4–1.6 ns
- write: preventExtensions и seal пишут в существующие поля так же быстро, как {}, а freeze в кидает исключение ~2245 ns (долго)

Вывод: читать frozen можно спокойно, дорого создавать (это обычно редко), а писать в freeze через try/catch не нужно, но в коде freeze может быть, если есть тесты, подтверждающие, что не пишем в поля

https://github.com/HowProgrammingWorks/Object

Что я понял по итогам работы над структурами данных для стандартной библиотеки Metarhia

Это же классическая тема, но ее мало кто хорошо осваивает в наше время, тем более в мире JS/Web разработки и во времена, когда все пишет AI. И даже если учили и знают, как делать хотябы простейший список, то нет привычки его использовати и знания остаются аккадемической теорией, невосстребованными вообще, а в коде массивы и объекты, ну максимум Set/Map. Почему же так случается?

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

Я за последний месяц собрал свои наработки за последние 15 лет и сделал и продакшен-версии кода и учебные примеры, записал много лекций и стримов по структурам данных. Буду делать примеры и скилы, а пока вот продакшен-реди реализация самых нужных структур тут https://github.com/metarhia/metautil

Passkey (вход без пароля)

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

При входе устройство подписывает запрос - фишинг и утечка пароля остаются в прошлом.

Минимальный пример на чистом Node.js и WebAuthn API: регистрация, вход, сессия.
https://github.com/HowProgrammingWorks/Passkey

А тут альтернативный вариант входа без пароля:

- Хранение ключей в OPFS (в браузере)
- Для генерации Web Crypto (ECDSA P-256)
- Без использования Web Authn, Passkey

https://github.com/HowProgrammingWorks/ChallengeSignIn

🧑‍💻 AI: зачем нужны структуры данных для JavaScript — практические примеры для бэкенда и фронтенда

Структуры данных в JavaScript обычно объясняют через их внутреннее устройство, API и оценку сложности Big O. А мы пойдем от реальных инженерных проблем: написание бизнес-логики, кода на JavaScript и TypeScript для backend и frontend, типовые проблемы в разработке: коррапт глобальных данных, гонку состояния, очереди, кеширование, история изменений, управление памятью и ресурсами.

Мы разберем, почему каждая структура решает определенную проблему, и уже как следствие, то что она что-то запрещает и чем за это приходится платить, но и какие плюсы мы получаем. От обычных Array, Object, Map и Set до Linked List, Persistent List, Heap, Circular buffer, Bloom filter, Stack, Queue, Append-only, Immutable lists and Records. Отдельно классифицируем структуры для доменного, продуктового, платформенного и системного кода.

https://www.youtube.com/live/qNAjrZ07un0

Новый набор в гильдию Next Tick

За что тебе платят, когда код пишет модель? Ответ, с которым мы работаем в Гильдии: за работу с ограничениями, decision framework, архитектуру, review, широкое мышление, глубокую экспертизу, умение коммуницировать с людьми и агентам.

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

Некоторые темы по архитектуре, которые мы уже рассмотрели:
- AI и архитектура: кто кем управляет, зачем уменьшать сложность
- Почему "большие задачи" почти всегда ложь — и как дробить работу
- Вертикальные слайсы vs горизонтальные слои в архитектуре
- Acceptance criteria как проверяемый контракт
- Planning for AI: explicit outcome, границы, definition of done
- Не весь техдолг равен, как продать рефакторинг на языке ROI
- Rewrite vs refactoring, AI-assisted migration: где AI ускоряет, а где производит новый долг
- Мифология в программной инженерии
- Architecture review: что реально должно блокировать merge
- Реактивные вычисления, модель акторов, конечные автоматы
- Мультипарадигменное программирование и построение DSL-языков
- Функциональные и нефункциональные требования
- ADR (документирование архитектурных решений)
- Управление характеристиками кода для построения нужной архитектуры

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

Что будет в ближайшее время:

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

Архитектура - это пересечение экономики и эстетики: предсказуемость из непредсказуемых частей, обратимые решения vs one-way doors, R&D вместо "надо все знать".

Заходите на сайт, там обзор и описание формата - https://nexttick.it/?utm_source=timur_tg_howprogworks

В NextTick мы регулярно проводим голосовые разборы для участников с платной подпиской. Один из последних стримов мы решили ненадолго открыть в Telegram-канале IT-Гильдии.

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

Это часовой разговор о том, что агентская эпоха уже меняет в работе разработчика: почему количество сгенерированного кода ничего не говорит о результате, где сохраняется ценность инженера и почему архитектура, code review и способность спорить с неверными решениями становятся важнее скорости написания кода. А еще — что изменения в GitLab, увольнения в Cloudflare и рост AI-рынка означают не для абстрактного «рынка труда», а для конкретного разработчика прямо сейчас.

Запись будет в канале до 2 августа. https://t.me/itguild_next_tick

Почему в JavaScript мире нет культуры использования структур данных?
Их неправильно учат, точнее, правильно, но этого мало, такие знания полезны только на задачках с литкода и на собесах, а вот на практике люди сразу забывают про структуры данных и реальный код только: [], {}, Set, Map

Я поискал, как их обычно преподают
- как устроены внутри и как работают
- как оптимизировать: CPU, memory
- как оценить вычислительную сложность
- как оптимизировать под V8, GC

Но нет даже попыток показать:
- как применить на реальной задаче
- как они делают код понятнее
- как они помогают экономить на AI

1 августа покажу примеры на реальном коде для бизнес-логики, системного программирования, бекенда, фронтенда: https://youtube.com/live/qNAjrZ07un0