Автор заметки на Habr описывает знакомый многим сценарий: с 2024 года LLM стали достаточно пригодны для генерации кода, и их начали подключать к проектам точечно — разобрать ошибку, набросать функцию, прикинуть архитектуру. Довольно быстро выяснилось, что без правил и договорённостей процесс превращается в бардак: модель уходит в дебри, забывает принятые решения, ломает работающий код и зацикливается на переписывании одного и того же. Итог — проекты закрываются медленнее, чем при ручном написании.

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

Какие сбои чаще всего ломают процесс

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

Эти сбои — не про «плохую модель», а про отсутствие рамок. Если задача сформулирована расплывчато, а результат никак не проверяется, модель будет заполнять пустоту собственными допущениями. Чем больше таких допущений, тем дороже разбираться постфактум.

Что зафиксировать до старта работы

Практичный минимум выглядит так. Во-первых, границы задачи: что именно меняем и что трогать нельзя. Во-вторых, способ проверки: тесты, линтер, ручной прогон сценария — что-то, что даёт однозначный ответ «работает / не работает». В-третьих, формат ответа модели: diff, отдельный файл, пошаговый план — чтобы результат было легко принять или отклонить целиком. В-четвёртых, журнал решений: короткие заметки о том, что уже пробовали и почему отказались, иначе модель будет возвращаться к тем же вариантам.

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

Как понять, что методичка применима к вашей ситуации

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

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

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