Шильдик «Опытный пользователь LLM»

Введение

Когда-то давно все шли учиться на юристов – времена требовали. В резюме крепко закрепился навык: опытный пользователь ПК. Со временем навык девальвировался, и теперь его не встретишь. Затем, в какой-то момент, все пошли в айтишников – времена требовали. Сейчас мы стоим на пороге, когда будет закреплен навык “опытный пользователь LLM”. Даже без объяснения, что это на самом деле значит.

Девальвация навыка как естественный этап

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

Эти события на поверхности; гонка версий моделей, архитектур, подходов только набирает обороты, и многое, очень многое изменится. Не изменится только одно – человек как профессионал. И об этом я хочу немного порассуждать вместе с вами.

Об инженере замолвите слово

По диплому я математик, но все-таки больше отношу себя к инженерам (они относят меня обратно :)). Но не инженером в типичном понимании IT. Это скорее склад ума или способ решения задач. Инженер не просто пишет код или настраивает систему, он задается вопросами: как это работает? Почему это сделано так? На что способна эта железка, программа, модель? Инженер в IT может быть тестировщиком, программистом, руководителем, да кем угодно! Хоть вахтером! – это было обычным делом в 90-е, сейчас будет стол и стул на ПВЗ. Важен принцип работы с задачами.

Есть по этому поводу прекрасный анекдот:

Физику, математику и инженеру дали задание — найти объём красного резинового мячика.

• Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости.

• Математик измерил диаметр мяча и рассчитал его по формуле через тройной интеграл.

• Инженер достал из стола свою «Таблицу объёмов красных резиновых мячей» и сразу нашёл нужное значение.

Таблица объемов красных резиновых мячей не про то, что инженеру достаточно идти по проторенной дорожке, а про то, что надо для каждой задачи подбирать оптимальный инструмент. Гвоздь можно забить и микроскопом, но удобнее молотком.

Знание фреймворков и конкретного ЯП ускоряет инженера, но незнание таковых не является сколько-нибудь значимым препятствием в решении задачи (сейчас тем более): — На каком языке пишешь? — А на каком надо? Мануал есть?

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

Нерешенные задачи и потерянные знания вокруг нас

Можно привести множество плохих и хороших инженерных решений. Но это решения инженеров и никуда мы от них не денемся. Они будут окружать нас всегда. Ниже я постарался привести несколько таких.

UX детства

Еще в детстве, когда мы с дедушкой ездили на его ГАЗ-69, я спрашивал: — А почему на одних машинах подсветка приборов зеленая, на других красная, а где-то просто свет лампочки? — Свет лампочки – потому что машина старая, к красной и зеленой быстрее привыкают глаза. — А почему у пассажира лампочка светит на ноги? — Потому что машина военная, карты смотреть.

Уже в университете на курсе по UI/UX нам рассказывали про цветовосприятие и морскую навигацию в сложных условиях, что пополнило мои знания. Купера я читал уже после университета.

Каждый сможет вспомнить то детское чувство познания нового.

Китайские машины, сенсоры и выдвигающиеся ручки

Когда я впервые увидел UX решения китайского автопрома, то очень сильно удивлялся. Ручки выдвигаются – выглядит круто, но как открыть дверь в случае ЧП? При движении в темноте большие экраны слепят, ничего толком не включить, нужны ценные миллисекунды на адаптацию зрения. Нащупать сенсоры совершенно нереально, все время включается то подогрев, то обдув, то автопарковщик – ну, это просто был аттракцион. В новых автомобилях начали появляться физические кнопки – инженерный цикл замкнулся.

Протоколы умирают – да здравствуют протоколы!

В дикие времена, когда ничего не было, каждый придумывал свой протокол, зачастую бинарный и оптимизированный под задачу: RPC, DCOM, CORBA (тут мы все-таки о более прикладных протоколах говорим, но про TCP/UDP не забываем). Затем начали появляться стандарты и был сформулирован UNIX-like подход к реализации текстовых протоколов. Так появились SOAP со множеством тяжелых надстроек и XMLSchema, затем как-то вожжи контроля начали ослабевать, и на арену ворвался JSON.

JSON становился популярнее и популярнее, поэтому его начали стандартизировать в JSON Schema, OpenAPI и оборачивать в Swagger-спецификации. Дальше появился YAML. Идею, думаю, вы поняли: новинка -> хаос -> стандартизация -> легаси.

LLM как новый виток эволюции инструментов

Вернемся к LLM. В инженерии LLM – это еще один новый, продвинутый инструмент. Аналогия очевидна: логарифмическая линейка -> компьютер с таблицами -> специализированные программы -> LLM и прочие нейросетевые решения. Вопрос лишь в том, как можно им пользоваться максимально эффективно, так, чтобы новые возможности стали тем самым журналом объемов красных мячей.

Вызовы

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

ИИ заменит профессию, но не человека

• Если вы программист<ваш ЯП или фреймворк> – вас заменят на ИИ

• Если вы <что-то>Ops и рулите кластерами – вас заменят на ИИ

• Если вы<ваша профессия> – скорее всего, вас тоже заменят на ИИ

Страшные вещи вокруг

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

Остается надеяться на профессионализм людей, но вспомните предыдущий раздел. Все придет к стандартизации, последним словом за человеком.

Галлюцинации != творчество

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

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

Проблемы

Трансформация профессий

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

В разработке ПО Закон Брукса или YAGNI никуда не делись. Когда агенты генерируют код за десятерых, сложность и объем кода растут неконтролируемо быстро. Быстрый рост генерирует технический долг. А как мы все знаем из опыта – технический долг рано или поздно должен похоронить проект.

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

Генерация технического долга

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

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

У фронтендеров как-то была присказка: если ты выучил фреймворк и применил в проекте, то он уже устарел. Сейчас, если ты запустил AI-gen продукт, то он уже устарел. Мало кто думает о том, как такие проекты сопровождать, как вносить изменения точечно, как переписывать те части системы, которые наполнены правками многолетней поддержки с неочевидными решениями. Кто уже с этим столкнулся, тот гораздо аккуратнее в восхвалении ИИ.

Бизнес и экономическая целесообразность зачастую выигрывают у технического долга, как бы плохо это не звучало.

Возможности

Наши руки не для скуки

Модели становятся все способнее, пока хаотично, но формируется обвязка в виде промптов, навыков, агентских циклов, систем памяти и пр. Эти телодвижения стремятся обуздать взрывной рост техдолга. Дальше последует стандартизация – тот же OpenSpec или Senar. В конце концов выживут лучшие решения, сформируют рынок, а рынку потребуются новые профессионалы. Это будут далеко не просто люди с шильдиком “опытный пользователь LLM” в резюме.

Идея – вечер – продукт

Пришла та пора, когда идеи очень легко стало проверять. За вечер можно сделать MVP и быстро проверить его жизнеспособность. Например, в игровой индустрии статистика весьма наглядная:

• 2024 год: доля игр с маркировкой об использовании ИИ составляла около 10,9%.

• 2025 год: показатель вырос до 19,9% (некоторые аналитические отчеты отмечали увеличение числа таких релизов в разы за полугодие).

• Первая половина 2026 года: доля релизов с ИИ-контентом достигла 30,8%.

• Прогнозы: по оценкам аналитиков, к 2027–2028 годам более половины новых игр в Steam будут создаваться с применением нейросетей.

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

ИИ делает это забвение не столь болезненным для автора, снижает цену ошибки.

Но нишевые продукты, которые, в действительности, никому, кроме автора, не нужны, прекрасно себя будут чувствовать на популярных доменах, таких как http://localhost:8080.

Кодим на ЯП -> решаем задачи

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

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

Практика

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

До своего Альцгеймера еще надо дожить, но пластичность мозга неумолимо снижается с годами. Я иногда ловлю себя на этой мысли, и приходится делать волевое усилие, чтобы преодолеть порог.

Инженерный принцип, который всегда со мной:

Выбирай конструктор, а не готовое решение, наблюдай и будь внимателен к деталям.

Как-то так сложилось, но во многих вещах я придерживаюсь этого принципа. Даже в неочевидных:

• Физика в детстве: Я упорно доказывал друзьям, что подкидываемая палка делает оборот вокруг оси без подкручивания. Если подкидывать молоток, это особенно заметно. В университете я узнал про эффект Джанибекова.

• Математика в школе: Спросил учителя про тождество разности квадратов, показал и объяснил какую закономерность я заметил. Выяснилось, что с этим открытием я опоздал на пару тысяч лет, но я же как-то ходил, считал и прикидывал, проверял – интересно :)

А дальше так:

• Windows и игры – да, но Linux в 9 классе, у которого вручную надо настраивать конфиги X11 без интернета – конечно же да;

• Apple, где все включено, – нет. Android без экосистемы – да;

• Купить менажницу за 400 рублей – нет. Купить фрезер за много денег, обзавестись остальным инструментом, которого не хватало, сделать менажницу и кучу всего другого своими руками – да;

• Почитать инструкцию после покупки – для слабаков. Почитать инструкцию после того, как что-то отвалилось, починить и помнить, что надо читать инструкцию – почему бы и нет;

• Купить подписку на Claude/Codex и вайб-кодить со скоростью 100500 проектов в секунду – имеем в виду. Купить миниПК на Strix Halo, ночами настраивать драйвера, собирать llama.cpp из форков и гордиться инференсом в 50 т/с – бесценно;

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

Выводы

Вот мы и пришли к выводу, что инженерия – это не только профессия, но и состояние души, принципы, по которым живет человек. Фреймворки, ЯП, железо и мир вокруг нас меняются. И Мы вместе с ними. Когда вам в очередной раз взгрустнется от происходящего вокруг, вспомните, что:

• Кто-то все равно будет запихивать 1 байт в свой микроконтроллер по ночам.

• Кто-то будет строить новые контракты в суровом энтерпрайзе и подметать за ИИ.

• Кто-то будет находить решения нереализуемых задач. Задаст правильные вопросы и сделает пусть и свои маленькие открытия.