Получить готовое решение и иметь основания ему доверять — разные вещи

Допустим, нужен поиск по каталогу. Поле ввода, запрос к серверу, список результатов. Поручаем это нейросети, получаем компонент, запускаем. Вводим слово — товары находятся.

Теперь вводим одно слово и, не дожидаясь ответа сервера, меняем его на другое. Ответ на второй запрос приходит первым — в списке товары для нового слова. Затем приходит ответ на первый запрос и заменяет содержимое списка результатами для старого слова.

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

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

Получить код и принять решение

Код появился. Код выполнился на одном примере. Код выдержал проверки, которые важны для задачи. Это разные основания для уверенности.

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

Знания помогают задавать такие вопросы.

Сколько нужно знать для проверки

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

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

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

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

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

Откуда возьмётся опыт

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

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

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

Что меняет помощь нейросети

Необязательно самому первым догадаться о порядке ответов. Эту версию может предложить нейросеть, коллега или статья. Даже с готовым исправлением можно сначала предположить, что произойдёт при задержке ответов, а потом проверить, совпало ли ожидание с результатом.

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

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

В эксперименте со школьной математикой (PNAS, 2025) обычный помощник на GPT-4 улучшал результаты тренировочных задач. На последующем самостоятельном экзамене эта группа справлялась хуже группы без помощника. В группе со специально подготовленным наставником статистически различимого ухудшения или улучшения на экзамене не обнаружили. Ему заранее передавали решения, типичные ошибки и учительские подсказки — существенно больше, чем просьбу не выдавать ответ сразу.

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

Что оставить себе

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

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

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