
Кто такие синьоры, если код пишет уже нейронка?
В каждой избушке свои калатушки.
Ты или твои друзья уже сталкивались с проблемой, что Вася из Рога-И-Копыта на позе синьора за 200к идет собесится в Шмяндекс, и не получает даже мидла.
И все уже начинают биться об заклад:
Цитата
А какого спрашивается хера я, его величество Василий, такой сложный алгоритм на работе реализовал, такой запрос к базе спроектировал, и еще свой контроллер к куберу ебанул. Почему я не синьор то???
Проблема в том, что синьорство определяется не сложностью кода, который ты можешь написать, а уровнем неопределенности, который ты способен вывезти.
А на собесе выясняется, что Василий отлично разбирается в БД, алгоритмах и Кубере, но даже малейшего понятия не имеет зачем и почему вообще им нужен был Кубер, и зачем они использовали Mongo для хранения данных пользователя.
Ах да, Вася сам же затащил монгу. Вглубину то базы он знает, но как их применять на практике - не имеет ни малейшего понятия.
Я был тем самым васей, кстати. И спустя годы я понял, почему мне с идеальными знаниями не давали сложные задачи - я бы их просто не вывез.
Из этого получается такая вот градация:
- Джунчик - фиксик. Получает задачку добавить end-point. Он и добавляет. А нахер он нужен? А зачем эта апиха вообще нужна если мы планируем миграцию и разделение сервисов - его особо не волнует.
- Миддл - батрачок. Делает уже полноценное добавление подписки. Разбирается с платежной апихой, проектирует модуль для микросервиса, или сам микросервис. Встраивает задачку в текущую архитектуру.
- Синьор - крококодер. Получает проблему бизнеса - нам нужны подписки. Учитывает требования биллинга, возвраты, повторные списания, финансовую отчетность и бла-бла-бла.

Как ты понял, каждый новый грейд заставляет бедного программиста брать на себя все больше НЕОПРЕДЕЛЕННОСТИ.
- У джунчика четкое техническое атомарное задание. Ему говорят что делать.
- Миддлу дали - должно заработать и все: надо посидеть, поприседать и придумать какой еще код надо набатрачить, чтобы кусочек программы работал.
- Синьору же сказали - надо, чтобы бизнесу было хорошо.
- А че такое хорошо? А че такое плохо?
- А насколько может быть плохо?
- А хорошо в этом квартале, или в следующем?
— Со всем этим поносом разбирается батрак-синьор.
Но тут есть нюанс. Senior-compiler или GPU инженер может не совсем хорошо понимать как работают откаты на уровне C-level’а, и зачем бизнесу понадобились такие GPU именно сейчас. Но батрачок знает, как изменение текущей архитектуры отразится на остальных компонентах системы. Он отлично ориетируется в низкоуровневой архитектуре, где те-же мидлы справится не смогу ни-за-что. Он может направлять команду и планировать крупные фичи. Он может оценить сколько времени может потерять команда, и какие риски это понесет.
Короче.
Важно
В разных доменах специфика разная:
Где-то это баги и endpoint’ы, где-то архитектура, где-то деньги, сроки, команды и бизнес-риски. Но правило остается одно:
Каждый следующий грейд разгребает более широкий и более дорогой по последствиям кусок фикалии.
И тут с двух ног залетают нейронки
… и полностью переворачивают этот рынок.
Нейронки-то могут и энд-поинт добавить, и микросервис спроектировать, и получается, что ребята из цепи ниже сеньора уже не нужны, поскольку нейруха полностью заменяет их обязанности.
Но проблема тут в том, что нейронка не сможет нести ответственность за написанный код. Если в твоем коммите указано Co-Authored by Claude Code, это не значит разъяренный лид побежит в офис антропиков. Вместо этого, он пойдет к Васе синьору с вопросами, почему ОН так плохо спроектировал систему.
У нейронки нет всего того контекста, что есть у CTO и CEO. Нет контекста что в голове у твоего менеджера или лида. НЕЛЬЗЯ просто так пойти, сказать нейронке: сделай, и довольным пойти играть в доту. Нейронка может не знать, что от какой то базы вы уже отказываетесь. Какой то модуль надо распилить, потому что у бизнеса есть планы по расширению приложения. Сколько раз лично ты сталкивался с ситуацией, что сам бизнес не знает что ему надо? Лично я - десятки.
Нейронка не знает, какие имеются требования к приложению с точки зрения SLA. Например, приложение должно запускаться за 5 минут, а не за 10. А это в корне меняет проектирование системы, и нейронке еще надо это объяснить.
Важно
В итоге получается - нейруха отлично может писать код, проектировать мироксервисы под конкретную задачу. И Синьору уже не надо ручками писать код - можно попросить нейронку это сделать. НО контролировать и направлять ее все еще надо. И поэтому задачи программистов все больше смещаются с написания кода в сторону проектирования, а грязная работа остается атоматизации.
Да, братцы синьоры больше код не пишут. Ну или почти не пишут. Если речь конечно не идет о крайне-низкоуровневых программистах, что на своем низком уровне начинают делить с чертями один из кругов ада. Привет хардварным чувакам и чувихам, вас нейронка точно не заменит.

Ну а что же делать джунам и миддлам? Тут ситуация еще интереснее, поскольку и джунов и миддлов как то надо взращивать, воспитывать и выводить на рынок.
Сейчас уже компании себе волосы на жопе рвут в попытке решить эту дилемму: как учить джунов, если их работа уже полностью ушла нейронкам?
А как они ее решают, мы обсудим в следующей статье.
Всех обнял, не теряйтесь.
Комментарии
Пока нет комментариев.
Войди, чтобы оставить комментарий
Войти