Как не потерять себя в эпоху ИИ

Обещание, что скоро код не придется писать руками, звучит далеко не первый раз. COBOL делали похожим на английский, чтобы программы были понятны не только программистам. Предшественник SQL назывался SEQUEL, то есть буквально Structured English Query Language. Потом появились ноукод-платформы. Ручной работы действительно становилось меньше, но программисты никуда не исчезли. Наоборот, их становилось только больше.

Теперь очередь дошла до больших языковых моделей (LLM). Дальше, для краткости, я буду называть их просто моделями. И вот здесь мы встретили финального босса: впервые инструмент по-настоящему, от и до, работает с естественным человеческим языком. Стало возможно писать целые программы не зная ничего о языках программирования.

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

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

И все же полноценной заменой программиста они пока не стали. Значит, наша ценность не только в знаниях, есть что-то еще.

Чем мы отличаемся

У модели нет вашего контекста.

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

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

В итоге модель может иметь почти все знания человечества и все равно быть не в состоянии заменить опытных специалистов.

Модель не несет ответственности.

Это вас дернут на выходных, вам объяснять тимлиду или бизнесу, почему сломан продакшен, и вам исправлять последствия. Но дело в том, что ответственность заставляет увидеть, к чему привело решение, а из этого появляется опыт.

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

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

Как мы получаем навыки

Раньше понимание часто приходило само, просто по ходу работы. Прилетает задача из незнакомой области, вы читаете документацию и Stack Overflow, пробуете разные варианты, ошибаетесь, дебажите. В итоге в голове складывается понимание реализации. Вы помните путь к решению, быстрее ориентируетесь в коде, можете объяснить сделанный выбор и ответить на какие-то вопросы.

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

Навык формируется там, где вы проделываете работу самостоятельно, в том числе через собственные ошибки.

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

Однако держаться за все подряд тоже нет смысла. Какие-то навыки действительно можно отпустить. Зачем тратить силы на то, что модели уже делают быстрее? Цель не в том, чтобы отказаться от прогресса, а в том, чтобы вместе с рутиной не потерять собственное понимание.

Остается решить, какие навыки стоит сохранять, а какие можно спокойно отпустить.

Что отпустить, а что сохранить

Критерий у меня получился один: помогает ли этот навык в том, в чем мы пока сильнее модели.

Отпустить.

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

Однако здесь важно не перепутать реализацию с пониманием. Код алгоритма можно попросить у модели. Но понимать его сложность, ограничения и пригодность для конкретной задачи по-прежнему полезно самому.

Сохранять и развивать.

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

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

Как это выглядит на практике

Почти в любой задаче есть четыре разных вида работы:

1. Постановка — что и зачем мы делаем.

2. Контракт — какие данные входят и выходят, где проходят границы и какие состояния допустимы.

3. Критерии правильности — как мы поймем, что задача решена.

4. Реализация — код и конфигурация.

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

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

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

Критерии правильности (тесты или условия приемки) лучше определить до того, как модель напишет код. Они отделяют правильное решение от правдоподобного.

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

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

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

Понять, сколько работы отдавать модели, помогают два вопроса.

Даст ли эта задача новое понимание?

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

Какие риски?

Чем выше цена ошибки и чем сложнее откат, тем меньше самостоятельности стоит отдавать модели. Вы должны представлять, что придется делать, если что-то сломается. Здесь участие нужно уже не ради обучения, а ради контроля над последствиями.

Как итог

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