Как ИИ и автоматизация вытесняют middle-разработчиков — и что с этим делать

1️⃣ Что уже произошло: ИИ, low-code и автоматизация меняют рынок

IT перестаёт быть «особенной» отраслью — теперь это просто бизнес, где каждый процесс оптимизируют под эффективность. ИИ, low-code и автоматизация уже сейчас забирают куски работы у разработчиков:

🔹Джуны и слабые middle-разработчики становятся не нужны. ИИ справляется с рутинным кодом, шаблонными задачами и тестированием. No-code-платформы позволяют бизнесу собирать приложения без программистов.

🔹Тестировщики и продакт-оунеры под ударом. А менеджеры, не разбирающиеся в технике, теряют ценность.

🔹Архитекторы и senior-разработчики тоже не в безопасности. Компании сокращают бюджеты, и дорогие специалисты теперь должны доказывать, что их работа критически важна.

2️⃣ Что будет дальше?

Через несколько лет рынок изменится ещё сильнее:

🔸Прикладная разработка превратится в «конструктор». Менеджеры будут собирать приложения из готовых блоков, а код писать только для сложных модулей.

🔸Порог входа в IT резко вырастет. Чтобы попасть в индустрию, нужно будет сразу обладать навыками сегодняшнего middle+.

🔸Останутся только две категории разработчиков:
- Те, кто автоматизирует автоматизацию (пишут инструменты для ИИ и low-code).
- Те, кто работает с фундаментальными системами (базы данных, инфраструктура, AI/ML).

3️⃣ Что делать middle-разработчику, чтобы выжить?

Краткий ответ – расти до сеньора. Для этого:

✅ Развивайте системное мышление. Учитесь видеть проект целиком, и не просто писать код, а осознавать, как он вписывается в архитектуру, а она, в свою очередь, строится исходя из бизнес-требований.

✅ Прокачивайте soft skills. Учитесь понимать стейкхолдеров, объяснять и отстаивать свои технические решения. Разбирайтесь в процессах разработки и людях, которые их создают и поддерживают.

✅ Разбирайтесь в AI и автоматизации. Передайте рутинные задачи ИИ, а сами сфокусируйтесь на сложных вещах.

📆 2 апреля на митапе [из Middle в Senior] подробно поговорим о том, какие навыки отличают сеньора от мидла, что изучать, чтобы перейти на следующий грейд, и чего не хватает именно вам.

Ведущие:
Павел Вейник - Solution Architect, Staff Engineer
Светлана Семёнова - Senior Software Engineer

Регистрируйтесь по ссылке и увидимся в среду!

Как проходят курсы в Hard&Soft Skills? Посмотрим, что обсуждают участники [Технического Лидера]

Немного приподнимем занавес и посмотрим, о чем говорили на одном из практических занятий курса.

1. Как применять шаблон решения архитектурных задач для презентации технических решений

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

🔸Выделять проблемные места и предлагать несколько вариантов их решения.
🔸Формулировать идеи так, чтобы их понимали не только разработчики, но и менеджеры.
🔸Учитывать критерии выбора: надежность, производительность, стоимость, удобство поддержки.

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

✅ По отзывам, после внедрения шаблона количество коммуникаций по решениям уменьшилось в 2-3 раза за счет понятности, логичности и обоснованности этих решений.

2. End-to-end тесты и перегруженная очередь сообщений

На занятии разобрали кейс, где end-to-end тесты генерировали огромное количество событий, а RabbitMQ не успевал их обрабатывать. Это привело к падению тестов из-за тайм-аутов.

Как это получилось решить?

🔹 Внедрили пирамиду тестирования:

– Много юнит-тестов (десятки тысяч).
– Меньше компонентных тестов (сотни/тысячи).
– Совсем немного end-to-end тестов (десятки). Их задача — проверить взаимодействие сервисов, а не логику внутри компонентов.

🔹 Постепенно заменили тяжелые end-to-end тесты на моки или тесты более низкого уровня.

В результате время тестирования сократилось с 60 часов до 2-3 часов, просто за счет пересмотра подхода и удаления лишних end-to-end проверок. При этом качество контроля только выросло.

3. Код-ревью

Вопрос о код-ревью вызвал оживленную дискуссию. Вот ключевые моменты:

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

❗️Важно:
Если разработчики «дают слабину», возможно, проблема в мотивации или культуре команды, а не в код-ревью как таковом. Код-ревью — не просто формальность, а инструмент роста.

Друзья, завтра встречаемся на новый H&S Conclave доклад "RUST: панацея или просто ещё один язык?"

Rust продолжает набирать популярность, но стоит ли он хайпа? Разбираемся без иллюзий:

🔸 Ожидания от Rust — реальные и завышенные:
Кому на самом деле нужен Rust, за что его так ценят, и почему не все готовы переписывать свои системы на Rust.

🔸 Обзор принципов языка:
Четыре столпа Rust — это революция или просто эволюция? Как Rust обеспечивает безопасность и производительность на практике.

🔸 Как стать Rust-инженером:
Порог вхождения, подводные камни и советы тем, кто хочет освоить Rust.

🔸 Выводы:
Стоит ли переключаться на Rust прямо сейчас? И что важно знать перед тем, как сделать этот шаг.

Приходите! Регистрация по ссылке ⚙️🦀

🔥 Уже сегодня вечером поговорим о лучших практиках Code Review! Приходите послушать опыт спикера и поделиться своими инсайтами.

🗓 Когда: 10 апреля, в 20:00 (GMT +3)

🎙 Спикер: Виктория Телюк — Senior Java Backend Developer, Code Quality Advocate

💡 В программе доклада:

‣ Статистика из реального кейса
Насколько нам удалось улучшить качество кода и какую роль сыграл post review.

‣ Проверенные практики для эффективного code review в команде.

‣ Топ-10 самых частых проблем при ревью кода
Рейтинг типичных ошибок и как их выявлять и предотвращать.

‣ Обмен опытом
Как организован процесс code review в разных командах: делимся подходами и обсуждаем, что работает лучше всего.

👉 Зарегистрироваться и оставить вопрос спикеру — по ссылке. До встречи!

Когда можно считать себя senior-разработчиком?

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

Вот ключевые признаки senior-а:

Автономность и ответственность. Senior способен самостоятельно ставить цели, планировать их достижение и нести ответственность за результат. Senior не просто пишет код, а думает о том, как его работа влияет на бизнес.

Сеньор — это тот, кто берет задачу, доводит её до конца и видит, какую ценность это приносит компании.

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

Soft skills. Умение общаться с коллегами из других отделов (продукт, дизайн, маркетинг), менторить junior-разработчиков и доносить свои идеи — критически важно.

Чем выше уровень, тем больше обсуждений и компромиссов с бизнесом.

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

Ты перестаёшь ныть о "неправильных" процессах и начинаешь думать, как улучшить бизнес. Это и есть переход в сеньорство

Можно ли считать себя senior, если не работал в этой должности, но запускал свои стартапы?

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

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

Когда ты работаешь в одиночку, твой код никто не проверяет. Ты можешь думать, что ты сеньор — но это не факт. Без взаимодействия и фидбэка расти трудно.

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

Как бороться с синдромом самозванца?

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

Отделяйте себя от навыка. Если не получилось — это не вы «плохой», просто пока нет нужного опыта.

Ведите дневник достижений. Записывайте положительные фидбэки, успешно завершённые задачи и ситуации, где вы проявили инициативу.

Разговаривайте с коучем или ментором. Иногда нужен кто-то со стороны, кто поможет объективно оценить ваши навыки.

Проходите собеседования. Даже если не планируете менять работу — это помогает понять, чего от вас ждут на рынке и как вы смотритесь на фоне других.

Не сравнивайте себя с идеалом. Всегда найдется кто-то круче. Важно сравнивать себя с собой в прошлом.

Помните, что senior — это не "всезнайка". Senior-разработчик тоже учится и ошибается. Главное — уметь быстро находить решения и исправлять ошибки.

Используйте синдром как мотивацию. Легкая неуверенность может подталкивать к развитию. Главное — не давать ей парализовать себя.

Senior — это не звание, а образ мышления

Если этого еще недостаточно, чтобы развеять сомнения в своей сеньорности, – записывайтесь на консультацию. За 15-30 минут с преподавателем вы определите свои сильные и слабые стороны, составите план развития и узнаете, чем на этом пути вам поможет курс [из Middle в Senior]. Подробности по ссылке 🔗

Навыки техлида: критическое мышление и problem solving

Один из главных навыков разработчика – это критическое мышление и умение решать проблемы.

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

💡 Problem solving — это способность находить решения даже в условиях неопределенности и ограниченных ресурсов. Для техлида это значит не просто "погасить пожар", а разобраться в первопричине проблемы, чтобы избежать её повторения в будущем, а зачастую – предвидеть проблему заранее. Это включает умение четко формулировать проблему, быстро исследовать возможные подходы и выбирать наиболее эффективное и рациональное решение.

Как меняется навык от middle до техлида?

Middle-разработчик владеет навыками problem solving на уровне конкретных задач. Он решает проблемы самостоятельно в рамках заданного контекста.

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

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

Как развивать критическое мышление и problem solving?

1️⃣ Практикуйте глубокий анализ. Вместо того, чтобы использовать первое попавшееся решение, всегда задавайте вопрос: "Почему именно так?" Рассматривайте альтернативы и их последствия.

2️⃣ Учитесь задавать правильные вопросы. Чем выше уровень вашей позиции, тем важнее качество задаваемых вопросов. Учитесь докапываться до сути проблемы.

3️⃣ Разбирайте кейсы и ошибки. Проводите ретроспективы и post-mortem-аналитику. Разбор реальных кейсов помогает увидеть слабые места в логике решений и выработать навык системного подхода к решению задач.

4️⃣ Развивайте системное мышление. Не смотрите на проблему изолированно. Учитесь видеть взаимосвязи между компонентами системы, их влияние друг на друга и долгосрочные последствия решений.

5️⃣ Работайте с ментором или коучем. Иногда необходим взгляд со стороны, чтобы понять, где вы мыслите шаблонно и упускаете возможности. Профессиональное менторство существенно ускоряет развитие этих навыков.

6️⃣ Приходите на курс [Технический Лидер] и развивайте эти навыки на практических задачах и в обсуждениях с преподавателем и другими senior+ инженерами. Записывайтесь на консультацию!

🚀 AI в разработке: от хайпа к реальности

ИИ уже не просто игрушка — он реально пишет код, помогает ускорять команды и меняет подход к разработке. Но как всё это выглядит вживую, а не в презентациях?

Приходите завтра на доклад — Денис Филипкин поделиться личным опытом. Поговорим:

🧩 AI в коде — как он меняет игру и чего ждать дальше

🧩 Мой опыт — где AI помог, а где только мешал

🧩 Кейс с Cline — конкретный проект и что получилось

🧩 Q&A + обмен опытом — обсудим, кто как работает с AI

📅 22.04 в 20.00 GMT+3

Зарегестрироваться и оставить свои вопросы можно по ссылке. До встречи!

👉 Друзья, мы уже стартанули доклад про опыт использования AI в разработке, успевайте присоединиться к нам в Google meet

🎙 GenAI under Control: Evaluation & Guardrails. Part 2

Сегодня встречаемся в 20:00 GMT+3 на докладе H&S Conclave!

Продолжаем разбираться, как контролировать поведение LLM-моделей в боевых условиях. После теоретической базы — переходим к практике.
Во второй части доклада:
🔹 Что такое evals и как они помогают оценивать точность и релевантность промптов
🔹 Как использовать guardrails — для управления, фильтрации и ограничения поведения модели

📺 Если пропустили первую часть — запись доступна на YouTube!

👤 Спикер: Вадим Гацура, VP of Engineering @ Viio

👉 Зарегистрироваться на ивент и оставить свой вопрос можно по ссылке

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

Различие в адаптации между джунами и сеньорами, в сочетании с финансовыми последствиями использования ИИ-агентов, приводит к сценарию «мести». Компании, чтобы оставаться конкурентоспособными с помощью ИИ-агентов, должны резко увеличить расходы на LLM. Если им придется сокращать расходы для оплаты токенов, они, вероятно, будут сокращать более дорогих разработчиков, которые скептически настроены по поводу ИИ, в пользу более дешевых младших разработчиков, которые быстро адаптировались. Таким образом, джуны, быстрее освоившие ИИ и стоящие дешевле, получают стратегическое преимущество и могут отомстить и «выбросить неудачников-сеньоров с острова».

https://sourcegraph.com/blog/revenge-of-the-junior-developer

На вашем проекте все хорошо?

Проверьте это с чек-листом, охватывающим ключевые аспекты: качество кода, архитектуру, инфраструктуру и командные процессы.

🧩 1. Оценка качества кода
Начните с анализа метрик, отражающих сложность и поддерживаемость кода:

🔹Цикломатическая сложность: помогает определить сложные участки кода, которые трудны для понимания и тестирования.
🔹Технический долг: оценка объема работы, необходимой для приведения кода к стандартам качества.
🔹Покрытие тестами: показывает, насколько код защищен от регрессий.

Используйте инструменты статического анализа, такие как SonarQube, для автоматической оценки этих метрик.

🏗 2. Анализ архитектуры
Проверьте архитектуру проекта на соответствие следующим критериям:

🔸Модульность: насколько компоненты системы изолированы и могут разрабатываться независимо.
🔸Масштабируемость: способность системы обрабатывать увеличивающуюся нагрузку.
🔸Надежность: устойчивость к сбоям и возможность быстрого восстановления.

☁️ 3. Проверка инфраструктуры
Оцените инфраструктуру проекта по следующим параметрам:

🔹Автоматизация развертывания: использование CI/CD для ускорения и надежности релизов.
🔹Мониторинг и логирование: наличие систем, отслеживающих состояние приложений и инфраструктуры.
🔹Безопасность: проверка на уязвимости и соответствие стандартам безопасности.

Инструменты, такие как Prometheus для мониторинга и KICS для анализа безопасности инфраструктурного кода, помогут в этой оценке. 

👥 4. Оценка командных процессов
Проанализируйте процессы внутри команды:

🔸Скорость разработки: время от идеи до релиза.
🔸Качество коммуникации: насколько эффективно команда обменивается информацией.
🔸Удовлетворенность команды: уровень мотивации и вовлеченности участников.

Используйте опросы и метрики, такие как время цикла задач в Jira, для получения объективных данных.

🎯 5. Приоритизация задач после проверки
После проведения health check составьте список выявленных проблем и оцените их по двум осям:

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

Используйте матрицу приоритетов, чтобы определить, какие задачи следует решать в первую очередь.

💼 6. Обоснование необходимости проверки для бизнеса
Чтобы убедить бизнес в важности проведения health check, акцентируйте внимание на следующих выгодах:

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

Представьте конкретные примеры и данные, демонстрирующие улучшения после предыдущих health check.