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

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

Так появилась папка docs. Несколько md-файлов, и каждый — это решение, которое раньше я принимал молча.

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

Второй — код-стайл. Тут про наименование функций и переменных. Магические числа выносим в именованную константу рядом или в constants. Простота важнее «умности». Правило трёх — одно повторение нормально, второе заставляет задуматься, третий раз ты обязан вынести. Чистые функции без зависимости от стора и реактивности живут в helpers, а не размазаны по компонентам.

Третий — коммиты. Husky, commitlint, формат сообщения. Коммитишь не по правилам — хук не пускает и отправляет переделывать. Это не только про красоту истории, но и про то, что правила стали обязательными для всех одинаково — и для меня в том числе.

Четвёртый — компоненты. Чистый UI без знания о домене — в одну папку. Умные блоки, которые знают про сторы и живут минимум на двух страницах — в другую. И отдельно, куда класть новый компонент, потому что именно на этом вопросе обычно начинается хаос.

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

В корне лежит readme со ссылками на всё это: кликаешь — проваливаешься в нужный файл.

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

Но самое интересное осознание не про неё, а про меня.

Пока я писал эти файлы, выяснилось, что половина моих «правил» — не правила, а привычки разной степени уверенности. В одном месте я требовал одно, а сам неделю назад влил в master противоположное. Заворачивал на ревью то, что у меня самого лежало в соседнем модуле. Чтобы объяснить правила машине, мне пришлось их сначала по-настоящему придумать, а не держать в виде ощущения «так норм, а так нет».

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

Хорошую документацию теперь пишут не столько для людей — люди открывают её раз в полгода. Её читает модель — каждый раз целиком. А если за день не получается сесть и описать свой код-стайл — стоит признать, что его нет. Есть настроение того, кто делает ревью, которое все молча угадывают.

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