Отвечаю на вопрос из комментариев к видео:

вы говорите о важности умения проектировать ПО, умения писать архитектурные доки, умения подбора стека-технологий и т.п., а в чем проблема так же отдавать эту работу на плечи LLM и относится к итоговому коду и архитектуре, которая генерирует LLM - как к чему-то низкоуровневому?

Проблем несколько:

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

🔴Проблемы с контекстным окном и вниманием. LLM теряет и искажает существенные моменты по мере заполнения контекстного окна, причем современные LLM, которые имеют окно 1 млн токенов, по субъективным ощущениям вместо улучшения качества проработки решений, наоборот, ухудшают их.

🔴Неравномерность результата — проект собирается из частей. Иногда LLM делает довольно хорошо какую-то часть, а потом сваливается в галлюцинации для другой части.

В целом стратегия «разделяй и властвуй» в LLM пока плохо реализуема. В будущем, скорее всего, LLM сможет создавать и качественную архитектуру проекта, но пока до этого далеко.

ИИ база

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

Почему стали проверять знания ИИ?

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

Лично мне положение дел скорее радует, чем огорчает. Для инженеров (соеров) — это дополнительная возможность карьерного роста, да, снова надо учиться новому и уходить в сторону M-shape, но так было всегда — учись лавировать или уходи из профессии.

Для джунов ситуация стала сложнее — кроме обязательного System Design, появляется "покажи, как ты умеешь с агентами работать". И если по системному дизайну еще можно измерить нагрузку городами и как-то проскочить со словами "ну что вы от меня хотите, я ж только учусь", то по ИИ нужно показать хотя бы базовые практические навыки, и здесь все зависит от желания развиваться, так что шансы есть, особенно если подкачать базу.

Сейчас в приоритете агенты (с постепенным переходом к командам агентов и оркестрации), нужно уметь:

Теория:

- промпт-инжениринг — нужно рассказать про принципы, подходы, техники рассуждений и т.д.
- контекст-инжениринг — нужно объяснить, что такое контекстные окна, «загнивание» контекста, управление вниманием, RAG и т.д.
- обосновать выбор модели под задачу (например, тебя просят разработать небольшую фичу за разумное время и потребление токенов — тут главное не гонять дорогую модельку на задачах, а показать, что ты понимаешь, где проходят «границы возможностей»);
- архитектура агентов (включая команды агентов)

Практика

Например, задача на 20–30 минут, где нужно показать основные моменты разработки с агентами. На собеседовании дается живой кейс с уже настроенным агентом (либо можно взять свой привычный инструмент) и нужно:

- построить структуру проекта c учетом spec-driven development, ADR и т.д.;
- подобрать набор инструментов (в том числе MCP) и скиллов;
- разбить задачу на этапы (планирование, проектирование, реализация, контроль);
- решить проблемы галлюцинаций и в завершение сделать качественное ревью результата (т.е. показать, что именно «вы» будете делать и почему human in the loop так важен).

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