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

А правда ли найм умирает?

Сразу предвидя ваши ужасы и крики, хочу заметить: я не считаю, что рынок IT мёртв и не собираюсь раздувать эту 100 раз пережёванную тему в этой статье. По моему опыту ^[1] и опыту моего окружения всё вполне себе живо. Люди устраиваются с нуля на стажировки без опыта, спокойно ротируются между бигтехами, растут по грейдам и зарплате и в целом не готовятся пока к жизни под мостом.

Но есть нюанс. Если смотреть не только на личные кейсы, а на сухую статистику, картинка становится чуть менее радужной. По данным hh.ru ^[2] и аналитике Хабра, в 2025 году количество IT-вакансий сократилось примерно на 25-30% год к году по сравнению с 2024. Это ещё не апокалипсис, но уже вполне себе тревожный звоночек. Особенно для тех, кто привык хорошо жить, вкусно кушать и планировал встретить старость на побережье, а не в очереди за соцпомощью.

И вот тут появляется неприятный, но логичный вопрос. А что делать, если однажды кремниевый мозг ^[3] придёт за мной? Заменит часть моей работы, а на новую позицию меня либо не возьмут, либо возьмут, но с условиями, после которых начинаешь гуглить «Топ-10 рецептов из макарон и гречки»?

А теперь представь, что в программировании уже давно существует место, где нет созвонов, аджайлов, бюрократии, performance review и трекинга времени. Где реально свободный график, работа из любой точки мира и доход не привязан к твоим жопа-часам перед монитором. Более того, он может спокойно расти даже тогда, когда ты решил сегодня не геройствовать и просто пожить жизнь. А ИИ не мешает, а только увеличивает твой доход.

Решения проблемы.

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

Но пообщавшись с большим количеством друзей и знакомых из IT, выяснилась интересная деталь. Примерно 60-70% видят для себя ровно такой же выход. А это уже проблема. Рынку банально не нужно столько менеджеров. Да, системы растут, спрос на менеджеров тоже растёт, но точно не с той же скоростью, с которой растёт и развивается количество разработчиков.

И в какой-то момент я пришёл к довольно очевидному выводу. Возможно, стоит смотреть не на рост внутри компаний, а за их пределами. Там, где не работают все эти корпоративные правила, грейды, performance review и где можно заниматься тем, что тебе реально интересно.

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

И тут важно честно признать одну вещь. Разработчик в большинстве своём технарь. Как бы нам ни хотелось думать, что мы все немножко Стивы Джобсы, если ты полжизни писал код и возился с системами, то ты умеешь писать код. А не продавать, не находить боли ^[5] пользователей и не развивать продукты. Это не плохо и не хорошо, это просто разные навыки. А любой навык появляется только через практику. И в классической работе разработчика этой практики почти нет.

Что с этим делать? Ответ на самом деле довольно очевиден. Набираться опыта. Желательно с минимальными рисками и без резкого ухудшения уровня жизни. Чтобы снизить риски, нужно уменьшить фактор удачи и постепенно наращивать опыт и навыки, превращая успех не в случайность ^[6], а в повторяемую формулу. А для этого нужно строить много продуктов. Чем больше, тем лучше.

Стартапы по три года разработки нам не подходят. Много долгостроев не настроишься. Поэтому фокус смещается на маленькие продукты. На решение одной конкретной боли пользователя. Учимся эту боль находить и делать под неё техническое решение за 1-3 недели. И вот тут как раз на сцену выходит ИИ. Он позволяет сильно сократить временные затраты, снизить риски и при этом всё так же прокачивать навыки поиска болей, маркетинга и всех этих бизнес-штук.

Поздравляю. Вот мы и изобрели инди-хакерство.

Почему разработчику вообще выгодно пилить маленькие проекты?

Во-первых, это отличный повод вспомнить, почему большинство из нас вообще выбрало этот путь. Лично мне всегда нравилось создавать свои продукты. Собирать их как конструктор, строить системы, которыми реально пользуются люди. Но с приходом в бигтех и корпорации этот детский интерес ^[7] быстро выветривается. Из-за огромности систем пропадает чувство «своего» продукта и гордости за него. В какой-то момент ты перестаёшь быть автором и становишься просто винтиком в очень большой машине.

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

Третий важный момент – маленькая цена ошибки ^[8]. В небольшой продукт ты вкладываешь пару недель времени и, условно, пару сотен долларов на маркетинг. Потерять это неприятно, но не критично. Гораздо легче закрыть такой проект, сделать выводы и пойти дальше, чем похоронить идею, над которой вы безуспешно работали несколько лет и влили тысячи долларов. Маленькие фейлы переживаются проще и дают куда больше пользы.

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

Не без ложки дёгтя.

Как бы красиво я ни расписывал всё выше, стоит понимать, что полностью радужно быть не может.

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

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

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

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

Также есть минус, который неочевиден на первых порах, но довольно быстро становится ясен. Пиление маленьких продуктов далеко не всегда способствует росту именно как инженера. Большинство таких проектов не требует сложных архитектурных решений, новых инструментов или глубокого ресёрча. Telegram-боты, расширения для браузера, простые сервисы часто пишутся довольно шаблонно и из раза в раз на одних и тех же подходах. Технологический стек нередко упирается в условный SQLite, пару API и минимальный бэкенд. Сама идеология подхода ограничивает развитие в глубину как технаря, но при этом расширяет понимание бизнеса.

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

Итог

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

Со временем это хобби вполне может перерасти в основной источник дохода. Причём зачастую более спокойный, гибкий и приятный, чем классический найм. Но важно честно понимать риски. Здесь нет гарантий, нет стабильности «по расписанию» и нет кнопки быстрого успеха. Этот путь требует времени, терпения и готовности ошибаться.

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

Если вам откликается эта тема и интересно проследить за моим путём, ошибками, находками и рабочими экспериментами, я делюсь всем этим и личным опытом из разработки в корпорациях у себя в Telegram-канале ^[9]. Без инфоцыганства, с цифрами, практикой и живым опытом.