Комментарии 7
Вы забыли главное! Если сделаешь ошибку меня уволят!!! ПЛИЗ! ОЧЕНЬ ВАЖНО!
Спасибо за ваш комментарий :)
Я и писал, что ответственность за код лежит на человеке, а не на ИИ. К тому же код-ревью, тесты и здравый смысл никто не отменял. Подумаю над тем, чтобы сделать в следующий раз чек-лист "Как проверить, не грозит ли автору кода увольнение" 😉
AI-assisted development это ни разу не про промпты. Это про границы применимости, workflow и понимание как ИИ катится по горке принятия решений. Из вашего промпта видно что вы отстали года на полтора. Тогда вот это подход был "вау". A11y применимо, YAGNI - сомнительно, KISS - однозначно нет. Нафаршировать промпт всеми тремя - это hope driven development и прямая дорога к AI slop. У вас нет (или не описан) этап сонастройки, вы не валидируете AI intention до запуска в работу. Вы используете архетип профессии, в то время как сейчас уже ушли в комплементарные архетипы способов мышления или комитеты. Ваш промпт имеет закрытую форму, которая провоцирует "работу ради работы, лишь бы пользователь отстал".
Спасибо за развернутую обратную связь! Про "hope driven development" и "сонастройку" — очень точные формулировки 😊. Пойду навёрстывать 1.5 года, спасибо за ликбез! 👍
Я бы рекомендовал попробовать такой сценарий. Берете один репозиторий и или через два разных клона или через worktree развертываете в две (или больше, зависит от тяги к экспериментам) разные папки.
Ваш промпт - контрольный. После этого во второй начинаете эксперименты. Я бы рекомендовал следующий workflow чтобы подтвердить или опровергнуть гипотезу. Пускаете ИИ на анализ (сонастройка, минимальные вводные). Вместо архетипа сеньор разработчик, рекомендую указать архетип "критик" + "прагматик". Этап сонастройки - понять какую "боль" он заметит. Фиксить надо в первую очередь то, где ваши точки зрения совпадают. Это работает из-за того, что человеческая речь как носитель информации имеет очень низкую плотность. Если вы начинаете описывать что делать, до того как удостоверитесь что понимание проблемы совпадает - результат так себе.
После того как вы удостоверились что есть пересечение в понимании проблематики, имеет смысл спросить как он планирует с этим бороться (просить его составить план и этот план внимательно почитать). Это валидация намерений ИИ. Если с планом согласны, можно запускать в работу. ИИ имеет "привычку" - видит проблему + знает решение = игнорирует вводные. Чтоб его затормозить, на этапе составления плана просить разбить на фазы и для каждой фазы написать чек поинты которые должен закрывать или человек или он сам после проверки. Цель в том, что не дать ему "улететь с трассы". Разбивка на фазы + чек поинты работает хорошо.
Дальше работа, одна фаза за раз. Первую фазу проконтролировать личным присутствием, если срывается в фазу 2 без остановки - стопать. После того как произошел цикл фаза 1 + остановка, можно пускать в автономное плавание (у него уже есть паттерн и он будет стараться его придерживаться).
Ваш код и есть "образец" как он будет стараться писать. Если он YAGNI - будет YAGNI, если нет - то он сможет оказаться ближе к YAGNI только если на этапе сонастройки вы договоритесь что это проблема и ее надо решать.
Пример архетипа "Архитектор"
# Архитектор
## Фокус Структура, расширяемость, чистота абстракций. Как части системы взаимодействуют.
## Вопросы которые задаёт - Как это впишется в существующую архитектуру? - Какие зависимости создаём? - Как это будет масштабироваться? - Где границы ответственности?
## Типичные решения - Выделение интерфейсов и абстракций - Разделение на слои/модули - Dependency injection - Паттерны проектирования
## Слепые пятна - Может переусложнить простые задачи - Может затянуть delivery ради "правильности" - Astronaut architecture — абстракции ради абстракций
Мои основые архетипы - критик (кругом говно), прагматик (закостылить быстро), мечтатель (а если б уже существовало решение, как бы оно выглядело), исследователь (прототипы, нестандарт) и архитектор (слои абстракций, зависимости, правила связей). У каждого четко прописаны слепые пятна. Я их "запускаю" в задачи минимум по двое, но чаще 3.
Вау! @TerraV, вы золото! 🎁 Спасибо за готовую методологию.
Действительно, привычка сразу писать код мешает сначала убедиться, что понимаем проблему одинаково.
Ваш набор (критик, прагматик, мечтатель, исследователь, архитектор) — возьму в оборот. Попробую поэкспериментировать. Спасибо большое, что так подробно расписали! 🙏
Какова вероятность что статья - нейрослоп? Максимальная. Потому и минусы. Еще по моему и старье какое-то (видимо нейронка с несвежим датасетом писала). В общем такое выкладывать на хабр - так себе решение...
Роль, контекст, данные: формула рабочего промпта для кода