Ask HN: Какова текущая траектория развития senior-инженера?
Ask HN: What is the current trajectory of a senior engineer?
Я всё чаще задумываюсь: когда потребность в человеке в цикле проектирования исчезнет? Учитывая, что LLM обучаются с подкреплением на всём, что можно оценить как правильное или неправильное (код, математика), что мешает Anthropic, OpenAI и другим внутренне создавать (и, возможно, покупать) датасеты хорошей и плохой архитектуры и обучать на них модель? В 2024 году LLM были просто навороченным автодополнением, а сейчас говорят о «фабриках ПО» с агентами — что, по-вашему, останавливает это развитие? Почему архитектура ПО всё ещё будет сложна для агентов даже через год-два? Я вижу всё больше примеров, когда разработчики игнорируют это и говорят: «у людей всё ещё есть место, чтобы направлять агентов и проектировать архитектуру». Я думаю (с точки зрения бизнеса), что потребность в реальных навыках программиста на 90% исчезнет через несколько лет, и люди вроде product lead и т.п. будут в выигрыше, так как у них больше навыков работы с людьми. Это было хорошее время.
Я думаю, что в ближайшие несколько лет мы увидим, как LLM возьмут на себя большую часть рутинного кодинга, но архитектурные решения всё ещё будут требовать человеческого суждения. Контекст, ограничения и компромиссы в реальных системах слишком многомерны, чтобы их можно было полностью уловить в обучающих данных. Агенты могут предлагать варианты, но окончательный выбор и ответственность останутся за людьми.
На самом деле, я вижу, что спрос на senior-инженеров растёт, а не падает. Компании отчаянно нуждаются в людях, которые могут понять, что строить, и как это интегрировать с существующими системами. LLM отлично справляются с изолированными задачами, но когда дело доходит до взаимодействия с унаследованным кодом, политиками безопасности и требованиями соответствия, нужен человек. Так что траектория — это смещение от написания кода к проектированию и надзору.
Я работаю в крупной tech-компании, и мы уже используем агентов для генерации кода, но их вывод проходит через ревью инженеров. Проблема в том, что LLM не могут объяснить, почему они приняли то или иное архитектурное решение, и не могут адаптироваться к меняющимся требованиям без явного переобучения. Пока не будет решена проблема интерпретируемости и адаптивности, люди останутся в цикле. Но да, роль senior-инженера меняется: меньше кодинга, больше управления агентами и коммуникации.
Я думаю, что через 5-10 лет senior-инженеры будут больше похожи на технических менеджеров продуктов, которые определяют, какие проблемы решать, и как измерять успех. Навыки программирования станут менее важны, чем понимание бизнес-контекста и способность эффективно делегировать задачи ИИ. Это не конец, а эволюция роли.
Мне кажется, что ключевой барьер — это не техническая возможность, а юридическая и репутационная ответственность. Компании не хотят, чтобы ИИ принимал архитектурные решения, которые могут привести к катастрофическим сбоям. Пока не будет чётких рамок ответственности и страхования, люди будут нести окончательную ответственность. Так что спрос на senior-инженеров, которые могут подписаться под архитектурой, сохранится.
- dimbletimbers
Мне кажется, разработчики и люди на HN сильно переоценивают, насколько средний человек знает о компьютере, интересуется им или хочет с ним взаимодействовать. Какой бы ни стала работа, если тебе нравится разговаривать с компьютером и ты знаешь, как заставить его делать что угодно, кроме показа почты или youtube, ты уже впереди планеты всей и, скорее всего, там и останешься.
- RugnirViking
Я бы предложил больше внимания уделять производительности, тестированию и наблюдаемости.
Человеческое понимание + качество/поддерживаемость — вот где деньги. Учись делать эти вещи с помощью агентов.
Не думаю, что инженеры действительно вымрут, хотя их вполне может стать меньше. Мне кажется, недавнее обсуждение на тему «использование AI — это навык» по ссылке https://news.ycombinator.com/item?id=50063427 хорошо отражает мои ощущения — есть чему учиться, и, вероятно, всегда будет, чтобы выжать максимум из этих инструментов. Значит, кому-то за это будут платить. Позаботься о том, чтобы ты был одним из них
- bradfa
До появления LLM у нас в командах разработки ПО уже были роли продакт-менеджеров, проект-менеджеров, скрам-лидов и т.д. Думаю, по мере развития разработки с использованием LLM эти роли и их пересечение с инженерией продолжат сливаться.
Не то чтобы инженеры не знали, что управление проектами, голос клиента и организация задач как посредник между инженерией и менеджментом — это то, что можно/нужно/следует делать. Просто раньше это было делегированием задач, потому что работы было больше, чем мог сделать один человек. Теперь все эти роли можно частично переложить на LLM, но наличие человека в цикле для руководства инженерией и взаимодействия с бизнесом/клиентом всё ещё будет ценно.
Понимание того, что строить в целом, что строить следующим, что будет позже и как продукт соотносится с бизнес-целями, — всё это по-прежнему очень человеческая задача.
- gregwebs
Senior-инженер и все позиции SWE станут больше похожи на технического лида.
Если ты можешь направлять AI и производить больше ценности на каждый потраченный $/время, чем не-программист, направляющий AI на разработку ПО, то ты всё ещё можешь приносить много ценности.
Для большинства вещей, не являющихся прототипом, это должно быть так уже сейчас. Работа изменилась с «написания кода» на «выпуск ПО». Технический лид.
Программные продукты, делающие всё более интеллектуальную AI-разработку ПО доступной, будут продолжать снижать потребность в участии инженеров-программистов. Но ПО также станет в 1000 раз больше. Так что возможности для тех, кто адаптируется, могут сохраниться.
- apimade
Потому что иногда плохая архитектура — это правильная архитектура, а хорошая архитектура — неправильный выбор.
Думаешь, у нас был бы DOOM от Кармака с «лучшими практиками»? Чёрта с два.
Я работал с невероятно талантливыми людьми, которые выбирали неправильную технологию, подход и дизайн для проблем, которые они могли бы предвидеть или предугадать, если бы видели это или похожую проблему раньше, или имели контекст об организации, клиенте или размере команды, управляющей предлагаемым решением. Но они этого не делают.
AI отлично даёт учебниковые и «корпоративные» решения; но по мере снижения стоимости производства кода — я думаю, ценность простых, удобоваримых решений будет расти. TDD и прочее тоже могут быть полезны, но в определённый момент это становится слишком абстрактным, слишком сложным, слишком трудным для понимания одним человеком.
В этот момент, я думаю, тест-менеджеры, понимающие пользовательские пути, будут на вес золота, а реальная ценность любого решения станет хорошим, представленным тестированием.