IT – Гильдия

Когда жизнь даёт лимоны - делай лимонад. Когда лимонад дают в день рождения — главное не кривиться и извлекать их этого уроки.

Доброе утро!
Желаем продуктивной недели😁

Хайп-ориентированная и AI-слоп архитектура

Такая архитектура может выглядеть убедительно и даже привычно. Любимый фреймворк, модная библиотека, serverless, редис, кафка, микросервисы. Все сразу. Желательно до того, как появилась понятная доменная модель.

Проблема не в технологиях. Проблема в том, что культ модных решений начинает заменять мышление. AI-слоп архитектура это следующий уровень той же болезни — хайпа-ориентированного программирования. Когда вместо инженерного решения появляется сгенерированный набор правильных слов. Компоненты вроде бы на месте. Диаграмма красивая. Термины актуальные. Но если спросить, зачем это все и где границы ответственности, какие инварианты защищает модель, где источник истины, как система деградирует, где транзакционные границы и что произойдет при повторной доставке события, все быстро превращается в туман.

Архитектура не обязана быть модной. Она обязана выдерживать изменения, нагрузку, ошибки людей, ошибки сети, ошибки данных и ошибки бизнеса. Архитектура зависит от того, какая у нас команда, какие сроки, другие цели бизнеса. Откуда AI может об этом догадаться?

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

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

— Тимур

Дешевый AI-рефакторинг производит новый долг

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

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

- Переименовать переменные.
- Разбить файл.
- Добавить абстракции.
- Переписать на модный стиль.
- Получить зеленые тесты.
- Сделать вид, что система стала лучше.

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

- Было плохо явно.
- Стало красиво неявно.

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

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

Дешевый AI-рефакторинг опасен именно тем, что выглядит профессионально.

Он создает код, который проще читать в pull request, и так и хочется принять, но сложнее сопровождать в системе. Код, который проходит ревью по стилю, но ломает архитектурную задумке. Код, который уменьшает локальную сложность и увеличивает системную.

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

— Тимур

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

- Бизнес боится, что вы сделаете систему, которую потом никто не сможет поддерживать
- Что ключевой разработчик уйдет, и вместе с ним уйдет контроль над продуктом
- Что сроки опять поедут, а реальной причины никто невозможно будет установить
- Что AI-бюджет сгорит, а результата не появится, и никто не предложит решения
- Что команда будет бесконечно "делать архитектуру", но не выпускать ценность
- Что старый код никто не понимает, а новый никак не могут довести до готовности
- Что интеграции сломаются, данные потеряются, а плана Б у нас нет, как и плана А, впрочем
- Что про безопасность команда вспоминает только после инцидентов
- Что разработчики выберут модные технологии, а не устойчивые решения
- Что AI нагенерирует много кода, но никто не контролирует, что там
- Что решение проблем строится только на героизме отдельных людей
- Что "почти готово" будет длиться месяцами
- Что команда будет спорить о фреймворках, а не решать проблему бизнеса
- Что технический долг будут скрывать до момента, когда он станет бизнес-проблемой

— Тимур

✅ Правильный ответ: Признаёте, что не согласовали план миграции, и предлагаете конкретный следующий шаг: например, включать strict только в новых модулях, не трогая старый код.

Традиционное заблуждение, в которое я сам попадал не раз - «окей, мне не принципиально» это не согласие. Это отсутствие возражений. Вы получили не поддержку, а нейтралитет — и интерпретировали его как мандат. Это распространённая ошибка при продвижении идей.

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

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

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

Но кроме выбора ответа, здесь есть ещё один нюанс, который я бы хотел обсудить. А именно поведение Максима. Если спросить 4 разных людей про то как они воспринимают, вы услышите разные мнения:

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

И здесь важно - вы не можете залезть в голову к Максиму. Но если вы хотите продолжать эффективное сотрудничество - очень важно всегда предполагать добрые намерения - любые ситуации в команде которые можно интерпретировать неоднозначно, интерпретировать с верой в людей. Во многом это работает как самосбывающееся пророчество - если вы верите что кругом враги, то вы этих врагов начинаете видеть. Это не помогает вам и не конструктивно. Именно поэтому я столько активно во многих чатах сопротивляюсь попыткам делать из менеджеров врагов (хотя они отстаивают, как и должны, часто противоположные инженерам интересов), а тем более из воих коллег

— Илья

Про коммуникации. Поиграем?

Вы три месяца продвигаете переход на TypeScript strict mode. Аргументы железные, данные есть. На последнем обсуждении опытный коллега Максим сказал: «Ну окей, если хочешь — делай, мне не принципиально». Остальные примерно так же. Вы восприняли это как зелёный свет и начали. Через неделю Максим на ретро говорит: «Мы потратили два дня на правку ошибок типов которые strict добавил — не уверен что оно стоит того».
Команда смотрит на вас.

Как не бояться за свою профессию в 2026:

Сегодня для успешной работы требуются совсем другие навыки. Одних технических знаний уже недостаточно. Нам нужны люди, способные брать на себя ответственность, объяснять компромиссные решения и отстаивать свою позицию перед «машиной», которая с большой уверенностью выдвигает неверные предложения. Лидерские качества. Наш последний набор сотрудников наглядно демонстрирует, насколько это редкость: из 2 253 кандидатов 2 069 были отсеяны, а приняты на работу — только 4. Коэффициент конверсии составил 0,18 %.

Источник: https://techtrenches.dev/p/the-west-forgot-how-to-make-things

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

Привет!
Не буду начинать с “ты застрял на плато и вот как из него выйти”.
Это правда, но от такого вступления хочется закрыть крышку ноутбука и смотреть в окно.

Начнем иначе: с одного конкретного наблюдения, которое можно проверить на своем проекте прямо сегодня.
Есть момент выхода на рабочий ритм программирования.
Ты уже умеешь делать задачи, которые от тебя требуют, но не всегда знаешь почему именно так.
Конкретный признак: тебя просят объяснить архитектурное решение, и ты говоришь “ну, так принято” или “так делали в предыдущем проекте”.
Так в статьях пишут и на конференциях рассказывают, но может это в твоей бульбочке так, может архитектура в других языках и платформах имеет лучшие рецепты и можно их перенести на веб. Это нормальная стадия - не понимать и сомневаться, но все же делать.
Именно здесь застревают Middle.

Синьор отвечает иначе: “Мы сделали так, потому что у нас есть ограничения, и это решение оптимально при конкретных условиях. Если условия изменятся - вот что мы поменяем.
Разница не в объеме знаний.
В том, что синьор знает контекст принятия решения.
А решения всегда принимаются в контексте.

Действие: возьми одно архитектурное решение в своем проекте, которое ты принимаешь как данность.
Найди коллегу или тимлида и задай один вопрос: “Почему мы делаем это именно так, а не иначе?”
Не чтобы оспорить - чтобы понять constraint который лежит в основе. Запиши ответ.
Это и есть начало архитектурного мышления - не изучение паттернов, а понимание почему они здесь применимы, а в другом месте нет.

— Тимур

🏛 Архитектура и искусственный интеллект
Советы из стрима в NextTick от 2026-06-13 — Тимур Шемсединов

🔸 Разбираем два направления влияния: как строить архитектуру, чтобы по ней хорошо писал искусственный интеллект, и как использовать AI для проектирования архитектуры
🔸 Документация становится ещё важнее: AI читает markdown-файлы, требования, meeting notes, issues, расшифровки и контекст, который люди обычно передают неформально
🔸 Паттерны, принципы и инженерные термины не исчезают из-за AI. DI, IoC, SRP, идемпотентность, грануляция, контракты и изоляция нужны, чтобы точно объяснять задачу людям и модели
🔸 Архитектура — не только структура папок, это декомпозиция, именование и композиция на всех уровнях: от выражений и функций до модулей, слоёв, сервисов, процессов и внешних систем
🔸 Код должен оставаться понятным человеку. У AI выше предел контекста и когнитивной сложности, но если система стала непонятной даже AI, человеку она уже давно недоступна
🔸 Архитектурные знания теперь нужны почти всем разработчикам: не обязательно быть архитектором по должности, но нужно понимать, что именно генерирует AI и можно ли это принимать в проект

🎯 Дальше мы разобрали реальные кейсы от участников стрима и Q&A секция

Всем привет!
Начинаем подборку полезных видео, сегодня обсудим:
Почему хороший код не спасёт твою карьеру — а вот это спасёт?

Ты сдаёшь задачу в срок.
Делаешь всё правильно.
Но менеджер всё равно пингует, нервничает и «не замечает» твоих идей.

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

В этом видео Илья разбирает:

— почему менеджер игнорирует твои предложения, даже если они объективно хороши
— как работает «счётчик доверия» в голове у менеджера
— и почему он падает, пока ты молчишь
— что такое демонстрация прогресса и почему она важнее, чем идеально написанный код
— почему делать сложные задачи
— это ловушка (если делать их неправильно)

Менеджер — не друг и не враг.
Это мембрана между тобой и всем, что давит снаружи.
Как с ней работать — в видео.

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

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

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

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

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

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

Что такое Гильдия Next Tick — и зачем она вообще нужна?

Мы много месяцев слышим одно и то же.
От людей с 5, 8, 10 годами опыта:
— «Варюсь в собственном соку. Расти некуда, но непонятно куда.»
— «Курсы прохожу — знания есть. Ощущения движения нет.»
— «AI помогает делать задачи, но уверенности не прибавляет.»

Это не жалобы.
Это точное описание того, где сейчас находится большинство middle+ разработчиков.

Гильдия Next Tick — это не курс.
Мы оба не верим, что курс решит эту проблему.
Это среда, где можно разобрать свой реальный кейс — не абстрактный пример из учебника, а то, с чем столкнулся вчера на проекте.

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

Три стратегии — выбери свою:
https://nexttick.it/

Вы пишете код с AI.
Но кто тут ведущий, а кто ведомый?

— Инженер, который управляет AI.
— Или AI, который незаметно начинает управлять инженером.

Все любят повторять: код пишет AI, а я набрасываю свои хотелки и даю архитектуру.

— Вы уверены, что не AI вами помыкает?
— Как вы даете ему архитектуру?
— Какие характеристики кода поддерживают вашу архитектуру?
— Или это уже не ваша архитектура?

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

— Как вы ограничиваете сложность кодовой базы?
— Как вы даете задания, чтобы стоимость использования AI завтра не съела бюджет компании?
— Как вы обеспечиваете управляемость кода, его понятность, удобство и скорость изменений?

— Тимур