Вы путаете не знаю умышленно или нет. Если в результате промпта была изменена строчка кода, которая прошла PR и попала в мастер. Имеет смысл кто был автором изменения? Я уж молчу про то что гарантий никто никогда никому не дает. Все поставляется AS IS.
И в дополнение вопрос - зачем нужно чтоб промпт в 100 случаях из 100 выдавал один и тот же результат? Когда мы разговариваем с людьми (и даже с разработчиками!) мы не падаем в обморок что один раз на "привет" он говорит "привет" а другой раз "здорово". Мы как-то уживаемся с мыслью что Васе надо рассказать контекст задачи, и может быть даже не один раз. И может быть даже так он напишет глупость и потом придет дефект с QA или вообще не дай бог правка от бизнеса.
Я считаю вообще вся ветка дискуссии "промпт не детерменирован" - гнилая изначально. Нам нужно чтоб промпт один раз написал как тут просят любители "детерменированный алгоритм".
Проблемы возникают тогда, когда нет четких границ ответственности. Я лучше высушу мозги тиме которая предоставила API и которая сама его не выполняет, чем залезу к ним, узнаю их потроха и напишу реализацию которая работает но не соответствует API.
Я очень хорошо понимаю описываемую вами боль. Действительно разные разработчики видят сложность совершенно по-разному. Кто-то может держать в своей памяти 35 сервисов и макаронную фабрику между ними. Кто-то говорит - вот API/Interface и на болту я вертел детали реализации - я следую контракту. Я сам сторонник последнего. Потому что когда приходится переключаться с проекта на проект, держать детали каждого в голове просто нереально. Но в то же время я потерял надежду что людей можно переубедить в диалоге. Может быть, лет через 5 они согласятся с вами. Но сейчас - шансы лысые.
Мне кажется вы сместили акценты. Там же явно сказано "Код должен быть настолько простым, насколько это возможно, но не проще." Это прямо тот принцип которым я руководствуюсь последние лет 10+. Это не про количество кб текста и не количество строчек кода.
С LLM я давно и тоже знаю чего от него можно ожидать а чего нельзя. И байты те посмотрел я не раз и не два (и не только я). И скажу больше, я по своей должности смотрю байты не только LLM, но и кожаных. И рука-лицо куда чаще случается у последних. И сцук объясняешь им, объясняешь, а они один хрен порой такую дичь творят.
20+ лет опыта корпоративной разработки. Все эти 20 лет - бэкенд, 15 лет фронт. Системы документооборота, лабораторные информационные системы, международное страхование, банковский сектор, ювелирка. В FAANG'ах не был, врать не буду. Последние 12+ лет основной работодатель - западные фирмы. В России были part-time проекты.
Представьте себе - вы РП, ваш разраб отсыпал вам байтов. Байты решили какую-то вашу задачу. Все рады за вас обоих (не от чистого сердца ;)). Но никто не может утверждать, что следующая порция байтов подойдет к очередной задаче. А проверять под микроскопом те байты, конечно же, никто не будет.
Без LLM скорее всего одна. Проблем не внес. Качество кода не хуже, чем если бы писал сам. Поведение предсказуемо. Всё это за счет того, что я могу перенести свое внимание на то что действительно важно - API, архитектуру и тому подобные вещи.
То, про что вы пишете и с чем я согласен (ну или это я нагаллюцинировал и вы про это не пишете) - ИИ плохо умеет определять границы своей компетенции, плохо умеет размазывать сложность по проекту тонким слоем. Это ровно то, где человек (пока) блистает, и ровно то место для синергии. Если всё что может разработчик, это написать промпт и во всем дальше соглашаться - это не разработчик, это вайбкодер как есть в худшем карикатурном понимании. Если разработчик (уровня сеньора или техлида) ставит задачу джуну или мидлу или другому сеньору в своем подчинении и потом проверяет код хотя бы просто мазнув по коду в PR - это стандартный воркфлоу и для ИИ. Если бы производители ИИ не пытались принудить сделать ИИ комфортным для человека, если бы не "наказывали" за каждое "не знаю" - комфортность использования ИИ ассистентов в разработке была бы еще выше. Но даже сейчас дает кратное ускорение. Главным образом за счет асимметрии. Вы можете читать и вычленять недостатки много быстрее чем писать код без недостатков самому. Навык работы с ИИ - нарезание задач на такие ломтики, когда на оценку качества кода у вас уходит не более 3-5 минут времени.
Каждый байт памяти не считают уже лет 25 минимум. И Scrum вообще не про дороговизну и сложность, а про предсказуемость. Вы можете относиться к ИИ как к бредогенератору, можете иначе - пока этот бредогенератор попадает в ожидания пользователя - он ваш конкурент (или помощник, тут зависит от того где ВЫ).
У меня сегодня за день закрыты три таски "полностью детерменированным кодом", в каждой из которых я не написал ни строчки кода руками. Побочный эффект - убрал легасевую ошибку архитектуры. Она конечно была мелкая, но была. Код стал лучше, софт стал лучше.
Ну да, ну да. А потом вы открываете для себя многопоточку. Хотя сказать откровенно, даже однопоточный код очень легко может скатиться в неоднозначность когда абстракции начинают сифонить или когда царство флаговой логики. Короч надо быть большим оптимистом что утверждать что "код всегда выполняется одинаково". К Хаскелу я это побоюсь относить, у них свой дивный мирок и я там не спец ни разу.
Промпт - это ТЗ
Поэтому вы и получаете хрень на выходе. Промпт ни разу не обязан быть ТЗ. Промпт это мышление разработчика выраженное в текстовой форме. Если разработчик не понимает что он делает, из промпта это сразу видно. И наоборот, если есть понимание что я хочу достичь, появляется консистентность в результате. Да, мелкие бантики могут отличаться. Да, Opus скорее всего выдаст более "красивый" код чем Sonnet. Но код будет (по факту уже есть в разных продакшн проектах) production ready.
С точки зрения РП это всегда был вайбкодинг. С точки зрения качества человеческого ресурса - всё было печально и до ИИ. Как говорится - посмотрите на человека с IQ 100 и погрузитесь в пучину отчаяния что половина человечества еще тупее.
ИИ - это великий разделитель. Те, кто используют мозги и дальше будут использовать. Те, кому мозги заменяли телевизор и ленты в соцсетях не почувствуют разницы. Да, первых на порядок (порядки?) меньше чем вторых.
А насчет кода что он лучше промпта я вообще категорически не согласен. Я видел столько говна за годы в профессии, что это высказывание для меня сродни "ассемблер лучше джавы потому что явно указывает какому регистру что делать". Это просто другой уровень абстракции. Сейчас в нормальных конторах PR состоит из "prompt + code". И если вспоминать "техники программирования из прошлого" - псевдокод, документирование - чем это отличается от промпта?
Довольно много экспериментировал с Reflection — самооценка агента. Итоговый вывод - невозможность объективной оценки изнутри агента. Ушел к A/B тестам и внешней оценке. Ставишь одну и ту же задачу для двух и более субагентов, результаты оценивает "поток-родитель".
Конкретно в Claude Code есть возможность "откатить" историю. Три раза Escape и появляется узлы (пользовательский ввод), можно выбрать насколько далеко шагнуть назад. Проблему context poisoning решает.
Звучит как шутка, но вполне может оказаться пророческой. Наблюдаю очень разную картину взаимодействия с ИИ среди своих коллег. Большая часть - уяк-уяк и в продакшн. Причем желательно с одного промпта и auto-accept всех изменений. Меньшая отслеживают "ход мысли" ИИ и осуществляют "контроль намерений". Там же на самом деле такое огромное количество красных флагов, перед тем как ИИ сделает эпическую глупость. Это не промпт-инжениринг, это вполне себе взрослая инженерная тема когда ты выстраиваешь рабочий процесс, где AI это инструмент со своим диапазоном применимости. Просто из-за того, что ИИ "говорит человеческим языком", кажется ну вот я ему в двух предложениях задачу поставил - всё же понятно.
Я бы рекомендовал попробовать такой сценарий. Берете один репозиторий и или через два разных клона или через worktree развертываете в две (или больше, зависит от тяги к экспериментам) разные папки.
Ваш промпт - контрольный. После этого во второй начинаете эксперименты. Я бы рекомендовал следующий workflow чтобы подтвердить или опровергнуть гипотезу. Пускаете ИИ на анализ (сонастройка, минимальные вводные). Вместо архетипа сеньор разработчик, рекомендую указать архетип "критик" + "прагматик". Этап сонастройки - понять какую "боль" он заметит. Фиксить надо в первую очередь то, где ваши точки зрения совпадают. Это работает из-за того, что человеческая речь как носитель информации имеет очень низкую плотность. Если вы начинаете описывать что делать, до того как удостоверитесь что понимание проблемы совпадает - результат так себе.
После того как вы удостоверились что есть пересечение в понимании проблематики, имеет смысл спросить как он планирует с этим бороться (просить его составить план и этот план внимательно почитать). Это валидация намерений ИИ. Если с планом согласны, можно запускать в работу. ИИ имеет "привычку" - видит проблему + знает решение = игнорирует вводные. Чтоб его затормозить, на этапе составления плана просить разбить на фазы и для каждой фазы написать чек поинты которые должен закрывать или человек или он сам после проверки. Цель в том, что не дать ему "улететь с трассы". Разбивка на фазы + чек поинты работает хорошо.
Дальше работа, одна фаза за раз. Первую фазу проконтролировать личным присутствием, если срывается в фазу 2 без остановки - стопать. После того как произошел цикл фаза 1 + остановка, можно пускать в автономное плавание (у него уже есть паттерн и он будет стараться его придерживаться).
Ваш код и есть "образец" как он будет стараться писать. Если он YAGNI - будет YAGNI, если нет - то он сможет оказаться ближе к YAGNI только если на этапе сонастройки вы договоритесь что это проблема и ее надо решать.
Пример архетипа "Архитектор"
# Архитектор
## Фокус
Структура, расширяемость, чистота абстракций. Как части системы взаимодействуют.
## Вопросы которые задаёт
- Как это впишется в существующую архитектуру?
- Какие зависимости создаём?
- Как это будет масштабироваться?
- Где границы ответственности?
## Типичные решения
- Выделение интерфейсов и абстракций
- Разделение на слои/модули
- Dependency injection
- Паттерны проектирования
## Слепые пятна
- Может переусложнить простые задачи
- Может затянуть delivery ради "правильности"
- Astronaut architecture — абстракции ради абстракций
Мои основые архетипы - критик (кругом говно), прагматик (закостылить быстро), мечтатель (а если б уже существовало решение, как бы оно выглядело), исследователь (прототипы, нестандарт) и архитектор (слои абстракций, зависимости, правила связей). У каждого четко прописаны слепые пятна. Я их "запускаю" в задачи минимум по двое, но чаще 3.
AI-assisted development это ни разу не про промпты. Это про границы применимости, workflow и понимание как ИИ катится по горке принятия решений. Из вашего промпта видно что вы отстали года на полтора. Тогда вот это подход был "вау". A11y применимо, YAGNI - сомнительно, KISS - однозначно нет. Нафаршировать промпт всеми тремя - это hope driven development и прямая дорога к AI slop. У вас нет (или не описан) этап сонастройки, вы не валидируете AI intention до запуска в работу. Вы используете архетип профессии, в то время как сейчас уже ушли в комплементарные архетипы способов мышления или комитеты. Ваш промпт имеет закрытую форму, которая провоцирует "работу ради работы, лишь бы пользователь отстал".
Вы путаете не знаю умышленно или нет. Если в результате промпта была изменена строчка кода, которая прошла PR и попала в мастер. Имеет смысл кто был автором изменения? Я уж молчу про то что гарантий никто никогда никому не дает. Все поставляется AS IS.
И в дополнение вопрос - зачем нужно чтоб промпт в 100 случаях из 100 выдавал один и тот же результат? Когда мы разговариваем с людьми (и даже с разработчиками!) мы не падаем в обморок что один раз на "привет" он говорит "привет" а другой раз "здорово". Мы как-то уживаемся с мыслью что Васе надо рассказать контекст задачи, и может быть даже не один раз. И может быть даже так он напишет глупость и потом придет дефект с QA или вообще не дай бог правка от бизнеса.
Я считаю вообще вся ветка дискуссии "промпт не детерменирован" - гнилая изначально. Нам нужно чтоб промпт один раз написал как тут просят любители "детерменированный алгоритм".
Проблемы возникают тогда, когда нет четких границ ответственности. Я лучше высушу мозги тиме которая предоставила API и которая сама его не выполняет, чем залезу к ним, узнаю их потроха и напишу реализацию которая работает но не соответствует API.
Я очень хорошо понимаю описываемую вами боль. Действительно разные разработчики видят сложность совершенно по-разному. Кто-то может держать в своей памяти 35 сервисов и макаронную фабрику между ними. Кто-то говорит - вот API/Interface и на болту я вертел детали реализации - я следую контракту. Я сам сторонник последнего. Потому что когда приходится переключаться с проекта на проект, держать детали каждого в голове просто нереально. Но в то же время я потерял надежду что людей можно переубедить в диалоге. Может быть, лет через 5 они согласятся с вами. Но сейчас - шансы лысые.
Мне кажется вы сместили акценты. Там же явно сказано "Код должен быть настолько простым, насколько это возможно, но не проще." Это прямо тот принцип которым я руководствуюсь последние лет 10+. Это не про количество кб текста и не количество строчек кода.
С LLM я давно и тоже знаю чего от него можно ожидать а чего нельзя. И байты те посмотрел я не раз и не два (и не только я). И скажу больше, я по своей должности смотрю байты не только LLM, но и кожаных. И рука-лицо куда чаще случается у последних. И сцук объясняешь им, объясняешь, а они один хрен порой такую дичь творят.
20+ лет опыта корпоративной разработки. Все эти 20 лет - бэкенд, 15 лет фронт. Системы документооборота, лабораторные информационные системы, международное страхование, банковский сектор, ювелирка. В FAANG'ах не был, врать не буду. Последние 12+ лет основной работодатель - западные фирмы. В России были part-time проекты.
Представьте себе - вы РП, ваш разраб отсыпал вам байтов. Байты решили какую-то вашу задачу. Все рады за вас обоих (не от чистого сердца ;)). Но никто не может утверждать, что следующая порция байтов подойдет к очередной задаче. А проверять под микроскопом те байты, конечно же, никто не будет.
Я поражен вашей квалификацией в гадании по астралу! А серьезная дискуссия будет?
Без LLM скорее всего одна. Проблем не внес. Качество кода не хуже, чем если бы писал сам. Поведение предсказуемо. Всё это за счет того, что я могу перенести свое внимание на то что действительно важно - API, архитектуру и тому подобные вещи.
То, про что вы пишете и с чем я согласен (ну или это я нагаллюцинировал и вы про это не пишете) - ИИ плохо умеет определять границы своей компетенции, плохо умеет размазывать сложность по проекту тонким слоем. Это ровно то, где человек (пока) блистает, и ровно то место для синергии. Если всё что может разработчик, это написать промпт и во всем дальше соглашаться - это не разработчик, это вайбкодер как есть в худшем карикатурном понимании. Если разработчик (уровня сеньора или техлида) ставит задачу джуну или мидлу или другому сеньору в своем подчинении и потом проверяет код хотя бы просто мазнув по коду в PR - это стандартный воркфлоу и для ИИ. Если бы производители ИИ не пытались принудить сделать ИИ комфортным для человека, если бы не "наказывали" за каждое "не знаю" - комфортность использования ИИ ассистентов в разработке была бы еще выше. Но даже сейчас дает кратное ускорение. Главным образом за счет асимметрии. Вы можете читать и вычленять недостатки много быстрее чем писать код без недостатков самому. Навык работы с ИИ - нарезание задач на такие ломтики, когда на оценку качества кода у вас уходит не более 3-5 минут времени.
Каждый байт памяти не считают уже лет 25 минимум. И Scrum вообще не про дороговизну и сложность, а про предсказуемость. Вы можете относиться к ИИ как к бредогенератору, можете иначе - пока этот бредогенератор попадает в ожидания пользователя - он ваш конкурент (или помощник, тут зависит от того где ВЫ).
У меня сегодня за день закрыты три таски "полностью детерменированным кодом", в каждой из которых я не написал ни строчки кода руками. Побочный эффект - убрал легасевую ошибку архитектуры. Она конечно была мелкая, но была. Код стал лучше, софт стал лучше.
Ну да, ну да. А потом вы открываете для себя многопоточку. Хотя сказать откровенно, даже однопоточный код очень легко может скатиться в неоднозначность когда абстракции начинают сифонить или когда царство флаговой логики. Короч надо быть большим оптимистом что утверждать что "код всегда выполняется одинаково". К Хаскелу я это побоюсь относить, у них свой дивный мирок и я там не спец ни разу.
Поэтому вы и получаете хрень на выходе. Промпт ни разу не обязан быть ТЗ. Промпт это мышление разработчика выраженное в текстовой форме. Если разработчик не понимает что он делает, из промпта это сразу видно. И наоборот, если есть понимание что я хочу достичь, появляется консистентность в результате. Да, мелкие бантики могут отличаться. Да, Opus скорее всего выдаст более "красивый" код чем Sonnet. Но код будет (по факту уже есть в разных продакшн проектах) production ready.
С точки зрения РП это всегда был вайбкодинг. С точки зрения качества человеческого ресурса - всё было печально и до ИИ. Как говорится - посмотрите на человека с IQ 100 и погрузитесь в пучину отчаяния что половина человечества еще тупее.
ИИ - это великий разделитель. Те, кто используют мозги и дальше будут использовать. Те, кому мозги заменяли телевизор и ленты в соцсетях не почувствуют разницы. Да, первых на порядок (порядки?) меньше чем вторых.
А насчет кода что он лучше промпта я вообще категорически не согласен. Я видел столько говна за годы в профессии, что это высказывание для меня сродни "ассемблер лучше джавы потому что явно указывает какому регистру что делать". Это просто другой уровень абстракции. Сейчас в нормальных конторах PR состоит из "prompt + code". И если вспоминать "техники программирования из прошлого" - псевдокод, документирование - чем это отличается от промпта?
Довольно много экспериментировал с Reflection — самооценка агента. Итоговый вывод - невозможность объективной оценки изнутри агента. Ушел к A/B тестам и внешней оценке. Ставишь одну и ту же задачу для двух и более субагентов, результаты оценивает "поток-родитель".
Конкретно в Claude Code есть возможность "откатить" историю. Три раза Escape и появляется узлы (пользовательский ввод), можно выбрать насколько далеко шагнуть назад. Проблему context poisoning решает.
Звучит как шутка, но вполне может оказаться пророческой. Наблюдаю очень разную картину взаимодействия с ИИ среди своих коллег. Большая часть - уяк-уяк и в продакшн. Причем желательно с одного промпта и auto-accept всех изменений. Меньшая отслеживают "ход мысли" ИИ и осуществляют "контроль намерений". Там же на самом деле такое огромное количество красных флагов, перед тем как ИИ сделает эпическую глупость. Это не промпт-инжениринг, это вполне себе взрослая инженерная тема когда ты выстраиваешь рабочий процесс, где AI это инструмент со своим диапазоном применимости. Просто из-за того, что ИИ "говорит человеческим языком", кажется ну вот я ему в двух предложениях задачу поставил - всё же понятно.
Я бы рекомендовал попробовать такой сценарий. Берете один репозиторий и или через два разных клона или через worktree развертываете в две (или больше, зависит от тяги к экспериментам) разные папки.
Ваш промпт - контрольный. После этого во второй начинаете эксперименты. Я бы рекомендовал следующий workflow чтобы подтвердить или опровергнуть гипотезу. Пускаете ИИ на анализ (сонастройка, минимальные вводные). Вместо архетипа сеньор разработчик, рекомендую указать архетип "критик" + "прагматик". Этап сонастройки - понять какую "боль" он заметит. Фиксить надо в первую очередь то, где ваши точки зрения совпадают. Это работает из-за того, что человеческая речь как носитель информации имеет очень низкую плотность. Если вы начинаете описывать что делать, до того как удостоверитесь что понимание проблемы совпадает - результат так себе.
После того как вы удостоверились что есть пересечение в понимании проблематики, имеет смысл спросить как он планирует с этим бороться (просить его составить план и этот план внимательно почитать). Это валидация намерений ИИ. Если с планом согласны, можно запускать в работу. ИИ имеет "привычку" - видит проблему + знает решение = игнорирует вводные. Чтоб его затормозить, на этапе составления плана просить разбить на фазы и для каждой фазы написать чек поинты которые должен закрывать или человек или он сам после проверки. Цель в том, что не дать ему "улететь с трассы". Разбивка на фазы + чек поинты работает хорошо.
Дальше работа, одна фаза за раз. Первую фазу проконтролировать личным присутствием, если срывается в фазу 2 без остановки - стопать. После того как произошел цикл фаза 1 + остановка, можно пускать в автономное плавание (у него уже есть паттерн и он будет стараться его придерживаться).
Ваш код и есть "образец" как он будет стараться писать. Если он YAGNI - будет YAGNI, если нет - то он сможет оказаться ближе к YAGNI только если на этапе сонастройки вы договоритесь что это проблема и ее надо решать.
Пример архетипа "Архитектор"
# Архитектор
## Фокус Структура, расширяемость, чистота абстракций. Как части системы взаимодействуют.
## Вопросы которые задаёт - Как это впишется в существующую архитектуру? - Какие зависимости создаём? - Как это будет масштабироваться? - Где границы ответственности?
## Типичные решения - Выделение интерфейсов и абстракций - Разделение на слои/модули - Dependency injection - Паттерны проектирования
## Слепые пятна - Может переусложнить простые задачи - Может затянуть delivery ради "правильности" - Astronaut architecture — абстракции ради абстракций
Мои основые архетипы - критик (кругом говно), прагматик (закостылить быстро), мечтатель (а если б уже существовало решение, как бы оно выглядело), исследователь (прототипы, нестандарт) и архитектор (слои абстракций, зависимости, правила связей). У каждого четко прописаны слепые пятна. Я их "запускаю" в задачи минимум по двое, но чаще 3.
AI-assisted development это ни разу не про промпты. Это про границы применимости, workflow и понимание как ИИ катится по горке принятия решений. Из вашего промпта видно что вы отстали года на полтора. Тогда вот это подход был "вау". A11y применимо, YAGNI - сомнительно, KISS - однозначно нет. Нафаршировать промпт всеми тремя - это hope driven development и прямая дорога к AI slop. У вас нет (или не описан) этап сонастройки, вы не валидируете AI intention до запуска в работу. Вы используете архетип профессии, в то время как сейчас уже ушли в комплементарные архетипы способов мышления или комитеты. Ваш промпт имеет закрытую форму, которая провоцирует "работу ради работы, лишь бы пользователь отстал".
Я подозреваю что ща получу каках тележку, но это прекрасно реализуется уже сейчас и ничего особого для этого не надо. В том плане что любой инженер с sonnet/opus может реализовать эту фигню на коленке. Чисто как proof или балабол приложу пару ссылок, но вы можете даунвоутнуть даже не переходя. Репозиторий гитхаб cziberpv/unity-bridge: Let AI agents see and control Unity Editor through plain files. 25 commands, lens system, screenshots, texture catalog. Пример текст в игру http://youtu.be/XSpitzJMyc4
Вы забыли главное! Если сделаешь ошибку меня уволят!!! ПЛИЗ! ОЧЕНЬ ВАЖНО!