Разбор: чем работа на малый бизнес отличается от корпоративной карьеры разработчика

Писать код стало дешевле. Отвечать за него — нет. Из этого разрыва растёт почти всё, что сейчас происходит с профессией: завышенные сроки, размытые роли и всё меньше мест, где новичок может спокойно набрать опыт.

Поводом для разбора стал ролик инженера Тео (YouTube-канал VoidFnC, больше восьми лет в профессии) — «I Hate Being a Programmer in 2026». В нём он разбирает, как отрасль реагирует на ИИ и что это делает с ожиданиями к разработчикам. Ниже — суть этих наблюдений и практический вывод: кому и когда имеет смысл строить не корпоративную карьеру, а решения для малого и среднего бизнеса.

ИИ вышел за пределы инженерных команд

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

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

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

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

Больше кода — не значит больше пользы

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

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

Если один человек производит изменения быстрее, чем команда успевает их осмысленно ревьюить, «рост продуктивности» просто переезжает в другое бутылочное горлышко. А когда что-то падает в продакшне, ответственность никуда не исчезает только потому, что код написал ИИ. Разбираться, чинить и объяснять всё равно инженеру.

От инженера ждут уже не только инженерии

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

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

Куда девается путь джуна

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

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

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

Два типа инженерной работы

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

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

Почему малый бизнес — это не «попроще»

У небольших компаний есть задачи, для которых не нужны усложнённые решения. Магазин на WooCommerce с медленным чекаутом. Деньги, уходящие в рекламу, без понимания, какие кампании вообще приводят клиентов. Рутинная административная работа, которую делают руками, потому что внутренний инструмент никто не собрал.

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

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

Чего не стоит романтизировать

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

Что действительно отличается, так это наличие прямого контакта между тем, кому нужна задача, и тем, кто её решает. Обсудили проблему, варианты, объём и бюджет. Сходится — работаем. Не сходится — можно отказаться. В корпорации такого рычага почти нет: приоритеты задают менеджеры, ресурсы распределяет руководство, а иерархия определяет, какие решения вообще можно оспорить. В здоровой компании эта структура работает на результат, в нездоровой — против. При этом сильные команды с наставничеством и реалистичными ожиданиями бывают и в больших организациях.

Как выбрать, не совершив типичных ошибок

Несколько вопросов, которые стоит честно задать себе до того, а не после:

• Что вам интереснее: искать проблему с нуля или поддерживать систему, которая уже работает?
• Выдержит ли ваш бюджет несколько месяцев без стабильной зарплаты?
• Умеете ли вы говорить «нет» заказчику, который не может сформулировать задачу?
• Готовы ли вы вести продажи и переговоры, а не только разработку?

Теперь про ошибки, которые встречаются чаще всего.

1. Считать демо доказательством сроков. Прототип и продакшн — разные объёмы работы, и разрыв не измеряется парой дней.
2. Строить сложную архитектуру под маленькую задачу. Иногда достаточно доработать то, что уже работает.
3. Брать проект без согласованного объёма. Бесконечно меняющиеся требования убивают маржу быстрее, чем сложная техническая задача.
4. Оценивать свою работу по количеству кода. Объём написанного ничего не говорит о пользе.

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

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