С 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 до запуска в работу. Вы используете архетип профессии, в то время как сейчас уже ушли в комплементарные архетипы способов мышления или комитеты. Ваш промпт имеет закрытую форму, которая провоцирует "работу ради работы, лишь бы пользователь отстал".
И совершенно зря. На эту тему недавно было исследование от гугла, societies of thoughts, было и тут на Хабре. Элементарно добавление описания ролей в промпт качественно меняет ответ во всех ЛЛМ что я пробовал (Opus/Sonnet, ChatGPT, Grok). Здесь же это реализовано нативно на стадии обучения. Субъективно разница в качестве ответа как была между ChatGPT 3.5 и 4. Я сам заливаю в промпт четыре роли - прагматик, критик, архитектор и исследователь.
Я боюсь что с предоставленным контекстом не смогу понять ни проблему, ни корректность предложенного решения. Я даже не понимаю как читать петли на диаграмме. Это параллельное выполнение или goto back?
Это классическая иллюстрация ситуации, когда ИИ оказывается умнее пользователя. Математика графов это идеальный инструмент для решения описанной задачи (неожиданно ветвление и есть граф). Но квалификации пользователя не хватило понять предложенное и был рожден очередной велосипед.
Из неожиданного - перевод документации именно прикладного ПО - одна из сложных для LLM. За счет того, что текст, который надо переводить отравляет контекст. Условная строчка "Click on OK button to close the dialog" воспринимается как прямая команда AI куда-то там кликнуть. Точно так же отравлением контекста при задаче перевода являются изолированные вопросы. ИИшечка порой забивает на часть "переведи" и начинает отвечать. Пока так, имеем что имеем.
С 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 до запуска в работу. Вы используете архетип профессии, в то время как сейчас уже ушли в комплементарные архетипы способов мышления или комитеты. Ваш промпт имеет закрытую форму, которая провоцирует "работу ради работы, лишь бы пользователь отстал".
Вы забыли главное! Если сделаешь ошибку меня уволят!!! ПЛИЗ! ОЧЕНЬ ВАЖНО!
Поддерживаю. Плюс заявлять 200 лямов зелени за 3 минуты видео - ни сове, ни глобусу это не нравится.
И совершенно зря. На эту тему недавно было исследование от гугла, societies of thoughts, было и тут на Хабре. Элементарно добавление описания ролей в промпт качественно меняет ответ во всех ЛЛМ что я пробовал (Opus/Sonnet, ChatGPT, Grok). Здесь же это реализовано нативно на стадии обучения. Субъективно разница в качестве ответа как была между ChatGPT 3.5 и 4. Я сам заливаю в промпт четыре роли - прагматик, критик, архитектор и исследователь.
Я боюсь что с предоставленным контекстом не смогу понять ни проблему, ни корректность предложенного решения. Я даже не понимаю как читать петли на диаграмме. Это параллельное выполнение или goto back?
Это классическая иллюстрация ситуации, когда ИИ оказывается умнее пользователя. Математика графов это идеальный инструмент для решения описанной задачи (неожиданно ветвление и есть граф). Но квалификации пользователя не хватило понять предложенное и был рожден очередной велосипед.
Из неожиданного - перевод документации именно прикладного ПО - одна из сложных для LLM. За счет того, что текст, который надо переводить отравляет контекст. Условная строчка "Click on OK button to close the dialog" воспринимается как прямая команда AI куда-то там кликнуть. Точно так же отравлением контекста при задаче перевода являются изолированные вопросы. ИИшечка порой забивает на часть "переведи" и начинает отвечать. Пока так, имеем что имеем.
Давайте без новояза. Сократит потребность с 10 до 1 это "заменит 9 разработчиков из 10".