HowProgrammingWorks - JavaScript and Node.js Programming

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

Новый набор в гильдию NextTick начался, заходим Что нового в материалах - Записи всех предыдущих тем (см. на сайте) - Новые лекции и стримы об архитектуре от Тимура - Новые лекции и стримы о коммуникации от Ильи - Курс по TypeScript от Ильи - Много материалов про AI Заходим, не стесняемся https://nexttick.it/?utm_source=timur_tg_howprogworks

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

Маркетологи давно не читают сообщения перед публикацией, а вы что, все еще читаете код?

🏛 Советы из стрима по архитектуре NextTick от 2026-06-13 — Тимур Шемсединов 💡 Документация становится важнее: AI читает markdown-файлы, требования, meeting notes, issues, расшифровки и контекст, который люди обычно передают неформально 💡 Паттерны, принципы и инженерные термины не исчезают из-за AI. DI, IoC, SRP, идемпотентность, грануляция, контракты и изоляция нужны, чтобы точно объяснять задачу людям и модели 💡 Код должен оставаться понятным человеку. У AI выше предел контекста и когнитивной сложности, но если система стала непонятной даже AI, человеку она уже давно недоступна 💡 Архитектурные знания теперь нужны почти всем разработчикам: не обязательно быть архитектором по должности, но нужно понимать, что именно генерирует AI и можно ли это принимать в проект

🚀 В IT-Гильдии появился открытый канал Мы с Ильей решили переместить часть тем туда, чтобы не нагружать основные каналы Итак, там будет - архитектура, коммуникации, программирование с AI, хардскилы По этим темам меньше будем постать тут и больше там - https://t.me/+f8QYKhgcI5EwOTZi

Кто хотел посмотреть как писать фронтенд и бекенд без фреймворков так, чтоб не было бойлерплейта, лапши из асинхронщины, были реактивные изменения, удобрая архитектура структура папочек, и т.д.: https://github.com/HowProgrammingWorks/WebComponents

QUIC and HTTP/3 Come To Node.js (finally) https://www.jasnell.me/posts/quic-comes-to-node

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

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

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

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

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

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