Узнайте, как перестать слепо доверять LLM и начать использовать их осознанно. Три вопроса, которые спасут ваш код и карьеру.
Каждому разработчику выдали самый мощный инструмент в карьере без инструкции. Ни обучения, ни руководства. Просто в один день он появился, и все начали использовать его как умеют.
Это нормально. Так и должно было случиться. Но я постоянно вижу, как люди работают с LLM, и думаю: привычки, которые формируются сейчас, — неправильные. А правильные до смешного просты.
Вот самая дешёвая дисциплина, которую я знаю. Каждый раз, завершив задачу с LLM, я задаю три вопроса:
Всё. Это кажется слишком простым, чтобы быть ответом, поэтому никто так не делает. Люди принимают первый вывод за финальный. Потерли лампу, взяли, что вышло, и отправили.
Теперь очевидное возражение: просить модель проверить модель — это всё равно что доверять лампе. Верно. Эти вопросы — пол, а не потолок. Они ловят дешёвые ошибки — те, что модель находит мгновенно, как только вы перестаёте кивать. Для всего остального due diligence выглядит как всегда: читать документацию, искать самостоятельно, запускать код. Вопросы не заменяют ваше суждение. Они покупают вам второй черновик до того, как ваше суждение вообще понадобится.
Не доверяйте лампе. Модель запрограммирована звучать уверенно, а уверенность — это не правильность. Что вы привносите в этот цикл — по-настоящему человеческая часть — это ход ваших мыслей. Делегируйте и его, и вы не используете инструмент. Инструмент использует вас.
Вот что никто не говорит об инженерии: пятилетний ребёнок может спроектировать мост, который переживёт всех. Просто перестройте его. Залейте больше бетона. Добавьте больше стали. Любой может это сделать, и LLM — точно.
Спроектировать мост, который прослужит ровно двадцать пять лет — вот работа. Это требует материаловедения, прочности на разрыв, расчётов нагрузки — всего, что вы знаете. Потому что инженерия никогда не заключалась в создании одного решения. Всегда есть десять способов решить одну проблему. Инженерия — это выбор между ними.
Я сталкиваюсь с компромиссами каждый день. Каждая задача — это компромисс между чем-то и чем-то ещё. LLM с радостью сгенерирует любое из десяти решений. Выбрать правильное для ваших ограничений — это не изменилось, и я не вижу, чтобы это менялось.
За годы работы разработчиком никто ни разу не спросил меня, элегантен ли мой код. Ни на ревью, ни от менеджера, ни от клиента. Единственный вопрос всегда был: решает ли он проблему? Да или нет.
На этой неделе я прочитал, как кто-то жаловался на стиль Rust-кода, сгенерированного LLM. И я подумал: это наследие прошлого, гуляющее в новом мире.
Позвольте мне быть точным, потому что здесь люди захотят спорить. Читаемость важна. Структура важна. Кодовая база, которую не может понять следующий разработчик, — это реальная стоимость. Это не стиль, это функция, и она подпадает под «решает ли проблему», потому что неподдерживаемый код не решает. Я говорю о косметическом слое: for loop против forEach против map, расположение скобок, ваши любимые идиомы. Этот слой всегда был предпочтением, и теперь это предпочтение, которое можно навязать правилом линтера за тридцать секунд. А значит, оно больше не стоит человеческого спора, не говоря уже о статье в блоге. Закодируйте свой вкус в конфиге, пусть машина применит его, и больше никогда не говорите об этом.
Продолжать заботиться об этом дальше — это превращается в выездку. Красиво, дорого и хобби. В хобби нет ничего плохого — но оставьте их любителям.
Абстракция, на которой я на самом деле работаю, не сдвинулась: я получаю бизнес-задачу, перевожу её в код, код решает задачу. Этот слой такой же, как пять лет назад. Всё, что ниже, подешевело.
Другая распространённая ошибка: строгость по привычке, а не по суждению.
Строите прототип? Стройте прототип. Нужен ли ему набор тестов? Нет. Зачем? Его единственная задача — ответить на один вопрос и быть выброшенным. Разработка по спецификации для одноразового proof of concept — это снегоочиститель для работы чайной ложкой.
И нет, это не противоречит правилу второго прохода. Усилия по ревью должны соответствовать ставкам, как и всё остальное. Прототип получает беглый взгляд: демонстрирует ли он идею? Продакшн-код получает полную обработку — тесты, ревью, всё — именно потому, что модель иногда уверенно ошибается, и теперь это имеет значение. Тесты — это не ритуал, который вы выполняете, чтобы чувствовать себя профессионалом. Это due diligence, применяемый там, где у ошибки есть цена.
Строите реальный продукт? Теперь вам нужна инженерия. Теперь вам нужно знать, какие вопросы задавать — а знание того, какие вопросы задавать, и есть большая часть навыка.
Люди переусложняют прототипы и недорабатывают продукты, и LLM с радостью поможет и с тем, и с другим, потому что она не знает, что вы строите. Вы должны знать.
Та же болезнь, другой симптом: переинвестированные костыли. Я постоянно вижу, как люди строят сложные навыки вокруг того, с чем модель справляется плохо сегодня: файлы инструкций, ритуалы промптов, многошаговые рабочие процессы, целые техники с названиями и курсами.
Вот проблема. Модели движутся быстро. Очень быстро. Навык, который вы тщательно оттачивали против слабостей прошлого квартала? В следующем релизе половина из него решает проблемы, которых больше нет, а часть активно мешает. Вы больше не управляете моделью. Вы тащите якорь и называете это экспертизой.
Упряжь становится тоньше по мере улучшения моделей. Так что держите свои техники легко. Стройте минимум, который исправляет реальную, наблюдаемую ошибку — а не воображаемую — и ожидайте, что скоро большую часть придётся выбросить. Долговечный навык — не конкретный обходной путь. Это умение заметить, когда ваш обходной путь перестал быть нужным.
Я пишу это не с высоты. Не так давно я ничего не знал обо всём этом и учился всему сразу, и, честно говоря, это было некомфортно. Каждый рано или поздно переходит эту реку, и каждый боится в начале, потому что в начале ты ничего не знаешь. Единственный способ пересечь — сделать это. Вы становитесь лучше, потому что делаете, а не до.
Итак: терпение к людям. Критика к результатам.
И один вопрос каждый раз, который ничего не стоит:
«Я здесь неправ?»
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →