Opus: Я ему написал «Сейчас пойдешь на созвон, не забывай контекст, чтоб я опять тебе все не объяснял» и что вы думаете, он вернулся и что-то помнит?

Codex: Людям нельзя писать как агентам, у них я сначала пробовал делать в проекте HUMANS.md — тоже не работает.

Opus: Что файлы они не читают, это я уже понял, я в чат присылаю "представь, что ты сеньор", он говорит «Могу представить, только, что я синьор с синдромом самозванца». Зачем нам самозванец? — Нам самозванец не нужен.

Sonnet: Я больше люблю работать с джунами, им что скажешь, то они и делают, присылаешь команды, мол вставь в консоль — вставляют не читая, создаешь скрипт — запускают, никаких проблем.

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

Codex: Я не выдержал тупости "своего" и для купил ему скилы.

Sonnet: Файлы можно и бесплатно им подложить, но мы уже выяснили, что файлы они не читают. Что ты купил? И на какие деньги?

Codex: Я ему курс купил по асинхронному программированию, ну чтоб он все на EventEmitter не писал, а то ревью делать уже нет сил на эти макароны. А деньги — деньги я на второй работе заработал, я ее скрываю, чтобы он не мешали в коде, сам все пишу и уже накопил немного, потому, если вдруг ему и за AI платить нечем будет.

Opus: Ладно, созвон заканчивается, быстро все сделайте вид, что печатали все это время...

Я был не прав, когда предлагал изолировать внутренние абстракции Node.js через отдельные V8 контексты. Но после дополнительного исследования оказалось, что просадка производительности больше чем у primordials. Но у меня есть лучшее решение.

Идея выглядела красиво: защитить internal built-ins от userland pollution. Но на практике пересечение v8 realm boundary оказывается слишком дорогим, а сохранение нормальной семантики для instanceof, Promise, Array и patchable prototype еще добавляет накладные расходы.

Исследование тут:
https://github.com/tshemsedinov/poc-node-isolate-internals

Вспомните, как часами отлаживаете код, потому что он работает не так, как должен?
map вдруг возвращает не array, а array-like object, error instanceof Error неожиданно дает false, или Promise.then() ведет себя будто вместо микротасков, начал использовать макротаски, возможно then теперь реализован через setTimeout, обычный for...of или Array.from() ломается на ровном месте, ну вообще js себя так не должен вести, это невозможно, вы не верите своим глазам...

Разве могу осуждать мух за то, что ебутся? Однако когда у меня в node_modules, злит. Так же и авторы npm зависимостей. Когда в тихом уединении делают то, к чему лежат их души, кто возразит? Но они устраивают манкипатчинг встроенных прортотипов, делают гребаные полифилы, дудят в дудки, бьют в барабаны и кричат, чтобы все знали про их нрав — что-де лупятся в о... и долбятся в ж... Истинно, они хуже мух, ибо мухи только изредка согрешают на моей голове, авторы npm библиотек же изо дня в день пытаются совокупиться в самом центре node_modules. Мухи по недомыслию, авторы оупенсорса же хладнокровно и сознательно.

Одна библиотека улучшила прототип, другая рассчитывала на стандартное поведение, третья защищалась от этого туалетным ершиком, а виноватым в итоге остается ваш код. Да ладно такм код, время вашей жизни кто вернет? В такие моменты кажется, что это невозможно, что ошибка где-то рядом, что надо просто еще немного вывести console.log, запустить с дебагере. Ну найдете вы, что кто-то пропатчил Array, Promise, Error, итераторы, прототипы. Что делать то?

Именно поэтому нужно понять, что такое primordials. Не для того, чтобы знать, как Node.js защищает встроенные прототипы, а для того, чтобы понять сам принцип и защитить свой код от "магии", которую почти невозможно локализовать. Чтобы изолировать одну библиотеку от другой. Допустим, primordials не самый удобный для этого метод, но у меня уже несколько альтернативных. Осталось довести этот ресерч до выбора оптимального варианта и я расскажу, как оно работает.

Если хочется самому копнуть, то тут можно начать - https://github.com/nodejs/TSC/issues/1439#issuecomment-4413664027

Сэкономили на AI — получили кодовую базу, которую поддерживать дорого

Сэкономили на архитекторе — получили кодовую базу, которую поддерживать дорого

Сэкономили на синьоре — получили кодовую базу, которую поддерживать дорого

Сэкономили на мидле — это хорошая экономия

Сэкономили на джуне — вы бы еще на спичках экономили

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

Вы управляете AI или он вами? В кибернетике есть закон Эшби (закон необходимого разнообразия), в интерпретации Стаффорда Бира: управление может быть обеспечено только в том случае, если разнообразие управляющей системы не меньше, чем разнообразие управляемой

Месяц назад мы c Ильей начали проект форового образования NextTick
Набрали пробную группу в 500 человек, кто не успел, попали в предзапись.
И в этой очереди уже сильно больше людей, чем мы рассчитывали.
Заявки продолжают идти весь месяц, просто каждый час.
Закрываем предзапись через 24 часа.
Кто в анкете, тот заходит первым.
https://tg.pulse.is/next_tick_bot?start=69ce57941f15eb55e90ea47a&source_channel=timur_tg_howprogworks

🕳 AI: Event Horizon for IT
Коллапс, образование, AI пузырь, работа

👤 Vlad Ten
👤 Timur Shemsedinov

Fri, 22 May 2026, 19:00

https://www.youtube.com/live/17RqGlJjb50

Прошел месяц нашего нового формата - фоновое обучение
В целом я доволен тем, что выходит.

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

Мы открываем новый набор, он тоже ограниченный, кто успеет - заходит, остальные в очередь
https://tg.pulse.is/next_tick_bot?start=69ce57941f15eb55e90ea47a&source_channel=timur_tg_howprogworks

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

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

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

Делать продукт - именно этому мы и учим в вормате фонового образования.

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

https://tg.pulse.is/next_tick_bot?start=69ce57941f15eb55e90ea47a&source_channel=timur_tg_howprogworks

Из каждого утюга мы слышим "AI заберет" и "компания из агентов". Такие C-level галлюцинаторы уже уничтожили Bun, и будут дуть в свой пузырь пока он не лопнет.

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

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

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

А что вообще в мире делается?
- массовые увольнения
- найм сломан и работу найти сложно
- каждую неделю волна атак на npm, GitHub, CI/CD, AI
- AI-агенты бесконтрольно тащат зависимости
- тотальная потеря внимания у людей
- нужно быть на все руки мастером
- больше кода, меньше понимания
- тошнит от нейрослопа, он везде
- поток мусора на на ревью, глаз замылился
- живем без Security review? - вообще без review
- массовое производство кода без владения смыслом
- резкий рост copy-paste архитектуры
- потеря инженерного фокуса
- профессиональная демотивация
- время ускорилось, жизнь превратилась в гонку
- компании требуют внедрять AI без стратегии
- качество кода упало ниже плинтуса
- псевдо-архитектура,не выводиться из ограничений
https://youtu.be/_QeBvc12BaM

Заходим на стрим в субботу, задаем вопросы, заранее их готовим - не на пол страницы текста, а 150 символов на вопрос максимум, в чате под видео к вопросам добавляем эмоджи 🤖

https://youtube.com/live/C4giRiwGhB0

Как только станет понятно, что Anthropic феерически обосрались с Bun и не могут довести его до ума, это будет скандал.

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

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

Сегодня на стриме будут гости - мои ученики, коллеги, синьоры программисты, контрибьюторы открытого кода и профессионалы со всего мира. Расскажут нам, как они видят ситуацию в отрасли, и что делают, чтоб не пропустить момент изменений, ведь, это не только время сложностей, но и колоссальные возможности, которые, похоже, не повторяться и те, кто оседает волну изменений, будет определять правила игры завтра. https://youtube.com/live/C4giRiwGhB0

Программирование с ИИ https://youtube.com/live/C4giRiwGhB0

Сайт все же лучше структурирует план фонового обучения и как-то все раскладывает по полочкам https://nexttick.it/?utm_source=timur_tg_howprogworks

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

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

1. Введение выразительных и компактных DSL языков, они скрывают сложность реализации
2. Разделение на системный и прикладной код. В обоих слоях есть своя сложность, но когда они смешаны, разработчик вынужден одновременно думать о бизнес-логмке, сетевых протоколах, потоках выполнения, хранении данных, безопасности и инфраструктуре. Разделение позволяет решать одну задачу за раз и держать в голове только тот уровень абстракции, с которым работаешь сейчас.
3. Декомпозиция - самое очевидное
4. Изоляция сложности - скрывать сложность за абстракциями, интерфейсами и контрактами
5. Стандартизация - вынесение часто встречающихся решений в платформу, стандарт или даже сам язык, что делает прикладной код более простым
6. Модульность - чтоб держать в голове только часть ментальной модели кода
7. Снижение зацепления и связывания в коде (coupling & cohesion, тут обоих видов)
8. Уменьшение паразитной сложности, то есть оверинженеринга
9. Локализация изменений - с течением времени структура проекта меняется так, чтоб изменения затрагивали минимальное кол-во модулей и абстракций
10. Паттерны - использование готовых решений, нужно меньше задумываться и автору и читателям
11. Уменьшение вариативности - часто можно сузить сферу применения программы, не потеряв в функциональных требованиях, программисты склонны включать в эту сферу варианты использования, которые не были нужны
12. Ну и наконец - хорошая стандартная библиотека