Опыт после обучения 10+ коллег: почему одни ускоряются в разы, а другие получают уверенную кашу.

За последние пару месяцев я обучил свою команду, как встроить LLM в рабочий процесс.

Не «поиграться с ChatGPT вечером». Не «задать вопрос, как сделать то-то». А именно начать использовать LLM в реальной работе: код, тексты, анализ, ревью, документация, исследование, планирование задач.

Мой вывод стал неожиданностью для меня:

LLM не работает за вас. Она работает с вами.

Это звучит как очевидность, но на практике именно здесь у большинства и ломается ожидание. Человек открывает чат, бросает туда задачу и внутренне ждет, что сейчас машина все сделает. Желательно правильно. Желательно с первого раза. Желательно без необходимости думать. Ну, или в несколько итераций...

Так не работает.

LLM может фантастически ускорить работу (у меня ускорила по ощущениям раз в 50, вот честно!). Но это происходит не потому, что модель забрала у вас мышление. Наоборот: это происходит тогда, когда у вас уже есть мышление, контекст и ответственность за результат.

Содержание

Один и тот же инструмент дает разный результат
LLM очень старается помочь
LLM не знает, что вы не сказали
Ответственность не делегируется
Почему сильные специалисты ускоряются сильнее
Как я теперь объясняю работу с LLM
Это усилитель, а не автопилот

Один и тот же инструмент дает разный результат

Самое интересное в обучении коллег было не то, как они осваивали конкретные команды или промпты. Это как раз быстро.

Интереснее было другое: один и тот же инструмент у разных людей давал совершенно разный эффект.

У одного человека LLM превращалась в ускоритель. Ключевой рабочий кейс — ты перестаешь смотреть в код и конкретику, держишь логику в голове, промптишь LLM туда, куда надо тебе.

У другого человека та же самая LLM превращалась в генератор уверенной каши: ожидаем, что ИИ сделает задачу за тебя, не до конца промптим, в результате ходим кругами.

И дело не в модели. Всегда дело в человеке, который с ней работает.

Можно грубо сформулировать так:

мало контекста  -> быстрая правдоподобная ерунда
много контекста -> быстрый сильный результат

LLM усиливает то, что вы приносите в работу. Если вы приносите структуру, она усиливает структуру. Если приносите хаос, она ускоряет хаос.

У меня есть грубая бытовая аналогия: алкоголь редко добавляет человеку что-то новое, он чаще усиливает то, что уже было. С LLM похоже: она усиливает исходное состояние системы — структуру или хаос.

LLM очень старается помочь

У LLM есть качество, которое одновременно делает ее офигенной и неудобной: она очень старается быть полезной.

Вы задаете вопрос — она отвечает. Просите план — она делает план. Просите код — она пишет код. Просите объяснение — она объясняет. И делает это уверенно, связно, быстро.

Это прекрасно, когда вы понимаете, что делаете.

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

Вы не объяснили архитектуру — она придумает удобную.

Не задали границы — она расширит задачу.

Не сказали, что нельзя ломать — она может это сломать.

Не описали критерии готовности — она объявит «готово» по своим критериям.

Потеряли общую структуру — получите локально логичный, но системно неверный кусок.

Отсюда моя любимая формулировка:

Галлюцинация часто начинается там, где закончился ваш контекст.

И это важный сдвиг в восприятии. Не надо относиться к галлюцинациям только как к дефекту модели. Очень часто это еще и симптом плохой постановки задачи.

LLM не знает, что вы не сказали

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

LLM в этом контексте не живет.

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

Поэтому фраза «AI сделал неправильно» — обычный симптом плохого управления.

Корректное отношение: «Я плохо объяснил, что значит правильно». Берем на СЕБЯ ответственность.

Это неприятная мысль, потому что возвращает ответственность (и геморрой) обратно человеку. Но без нее нормально работать с LLM невозможно.

Ответственность не делегируется

LLM можно делегировать много работы.

Можно попросить ее набросать варианты решения. Найти подозрительное место в коде. Написать черновик функции. Сформулировать тестовые сценарии. Упростить текст. Объяснить незнакомую библиотеку. Проверить diff. Найти edge cases. Придумать структуру документа.

Но ей нельзя делегировать ответственность.

Вы отвечаете за постановку задачи.

Вы отвечаете за полноту контекста.

Вы отвечаете за ограничения.

Вы отвечаете за архитектурную целостность.

Вы отвечаете за проверку.

Вы отвечаете за решение «можно выпускать».

С LLM ответственность не исчезает. Она просто смещается ближе к началу работы: к формулировке задачи, выбору рамок, объяснению контекста и проектированию проверки.

Раньше узким местом часто было «написать». Теперь все чаще узкое место — «понять, что именно должно быть написано, и доказать, что получилось правильно».

Почему сильные специалисты ускоряются сильнее

Я не верю в магический «правильный промпт», который внезапно делает из человека сильного инженера, аналитика или редактора.

Хороший промпт помогает. Но он не заменяет понимание предмета.

Чем лучше человек понимает область, тем больше пользы он получает от LLM. Он быстрее замечает ерунду. Лучше формулирует задачу. Видит, где не хватает контекста. Умеет разбить большую работу на проверяемые шаги. Не принимает красивый ответ за правильный. Не путает уверенность модели с доказательством.

Сильный специалист использует LLM как напарника:

проверь мою гипотезу
найди слабые места
предложи варианты
сравни подходы
сформулируй проще
покажи, что я упустил

Слабый пользователь чаще использует ее как магическую кнопку:

сделай задачу
напиши статью
почини код
придумай стратегию

Иногда и такие запросы работают. Но только на простых, изолированных задачах, где ошибка дешевая. Чем сложнее задача, тем более невозможным становится «сделай за меня».

LLM не освобождает от необходимости думать. Она делает мышление более производительным.

Как я теперь объясняю работу с LLM

Если коротко, я даю людям несколько правил.

  1. Не начинайте с «сделай». Начинайте с сути.

    Что мы делаем? Зачем? Какие ограничения? Что уже пробовали? Что нельзя ломать?

  2. Сначала просите план, а не финальный результат.

    План дешевле исправить, чем готовую реализацию. Если модель неправильно поняла задачу, лучше увидеть это до кода, текста или архитектурного решения.

  3. Держите в голове общую структуру.

    LLM может хорошо решить локальный кусок и при этом испортить систему целиком. Ваша задача — видеть целое.

  4. Проверяйте промежуточные шаги.

    Не надо ждать конца длинной генерации, чтобы обнаружить, что модель ушла не туда. Останавливайте раньше.

  5. Не принимайте «готово» без доказательств.

    Какие тесты запущены? Какой сценарий проверен? Что изменилось? Какие риски остались? Ключевое — продуктовая проверка (не код, а именно кейс).

  6. Заставляйте модель задавать вопросы.

    Если контекста не хватает, хороший следующий шаг — не генерация, а уточнение.

  7. Не отдавайте ей право расширять задачу.

    LLM любит быть полезной. Иногда слишком полезной. Если вы просили маленькое изменение, а получили попутный рефакторинг половины проекта — это не помощь, а регрессия.

Эти правила звучат скучно. Зато они превращают LLM из генератора случайных артефактов в рабочий инструмент.

Это усилитель, а не автопилот

После всех этих экспериментов я перестал воспринимать LLM как «инструмент, который пишет код» или «чат, который отвечает на вопросы».

Для меня это скорее усилитель. Типа NZT (кстати, кино офигенное, рекомендую: "Области тьмы").

Иногда очень мощный усилитель. Такой, который может за час помочь сделать то, что раньше занимало неделю (не преувеличиваю!!). Особенно если речь про черновики, варианты, исследование, рутину, проверку гипотез и быстрые итерации.

Но усилитель не выбирает, что усиливать.

Если вы приносите в работу хаос, он усилит хаос.

Если приносите поверхностное понимание, он быстро произведет поверхностный результат.

Если приносите структуру, контекст, вкус и ответственность, результат может быть выдающимся: быстрее, чище и глубже, чем раньше.

Поэтому главный навык работы с AI — не «писать промпты».

Главный навык — понимать, что вы делаете.

А LLM уже поможет сделать это быстрее.

Какой у вас опыт работы с LLM? Поделитесь, пожалуйста, в комментариях

Комментарии (21)


  1. Julius007
    25.05.2026 07:41

    Про пятый пункт очень в точку - на первых этапах сильно ломало нам взаимодействие.


    1. vladimirdyakov Автор
      25.05.2026 07:41

      Спасибо, что отметили. Тоже копий поломали..


  1. ARTARTART
    25.05.2026 07:41

    «Если вы приносите структуру, она усиливает структуру. Если приносите хаос, она ускоряет хаос.» - в этой точке, по ощущениям, и зарождается Неолуддизм :)


  1. VAF34
    25.05.2026 07:41

    Никогда не удавалось получить конкретный вопрос от LLM. Только вопросы типа, что вы хотите или чем вы располагаете.


  1. spiteman
    25.05.2026 07:41

    Почему вы используете "LLM" как определение? Ведь это больше про запуск локальной модели.


    1. vladimirdyakov Автор
      25.05.2026 07:41

      LLM - Large Language Model


  1. WhiteBehemoth
    25.05.2026 07:41

    Примерно так и есть. На личном примере (dotnet backend):

    1. (Настройка): с github/awesome-copilot взят один агент и пара скилз, проекты хорошо прописаны в copilot-instructions.md, MCP сервер на ADO (Azure DevOps, там все тикеты)

    2. Начинаю с того, что задача должна быть нормально описана в тикете. Степень "нормальности" зависит от сложности, субъективный параметр. Если задача большая, можно взять помощь LLM с grill me агентом

    3. В Copilot CLI начинаю с /plan, потом черновая реализация в автопилоте.

    4. Смотрю сотворённое. Если совсем не то, возвращаюсь к 2 или 3

    5. Если процентов 70-80 на первый взгляд норм, сортирую на то, что надо менять, и то, что не надо.

    6. Довожу до ума, тестирую, и выкатываю PR


    1. Gromilo
      25.05.2026 07:41

      1. Довожу до ума, тестирую, и выкатываю PR

      Аналогично. Но не понимаю как пройти последние 20% на автопилоте, а не руках


      1. WhiteBehemoth
        25.05.2026 07:41

        Я над этим думал и пришёл к выводу, что можно (через настройку банды агентов с кросс-проверкой), но всё равно с оговоркой, что это удорожает процесс и всё равно не гарантирует 100% годноты.

        А значит на текущем моменте не стоит потраченных на это усилий, поэтому "пока ждём" развития LLM и инструментов для работы с ними.


    1. vladimirdyakov Автор
      25.05.2026 07:41

      Огонь! Все чётко!


  1. evgenyko
    25.05.2026 07:41

    Интересные мысли!

    Особенно интересные в скобках, про производительность в 50 раз и про аналогию с алкоголем :)


  1. ipshon
    25.05.2026 07:41

    Интересно, продолжаем наблюдение - это пока он с нами работает, тренируется, потом за нас будет работать и жить!)))


  1. LsdMax
    25.05.2026 07:41

    А подскажите пожалуйста, куда засунуть фрактальность чтобы всё потекло.. Без возвратно?
    Нужна точка в LLM, делали.. Потом откаты.. Так вот прошу точку не возврата подсказать. ;)


  1. Petrovich_Z
    25.05.2026 07:41

    В последнее время занимаюсь обучением сотрудников довольно активно и выявил для себя очередную классификацию людей — по типу мышления. Про себя я называю их CPU и SSD. Люди-SSD имеют хорошую память, большого объёма и быстро умеют там находить прошлые решения. Но им требуется время и насмотренность чтобы накопить этот багаж, чтобы было где искать. Но зато потом это очень эффективные сотрудники в относительно узком диапазоне задач. И в этом их крутость, они не изобретают велосипед каждый раз. Ещё я их называю эрудитами.
    Люди-CPU все схватывают "на лету", выявляют паттерны и закономерности, им важнее принципы чем готовые решения. Они с самого начала готовы хвататься за самые сложные задачи и на этом растут, но скорость их работы как правило гораздо ниже, ведь если с подобной задачи прошло больше пары дней им нужно придумать частное решение (велосипед) заново на основе принципов. Их я называю интеллектуалами.
    Естественно большинство находится в той или иной точке этой шкалы.
    Мне кажется раньше у людей-ssd было преимущество, количество рутинных операций значительно превосходило количество исследовательских задач. И было время эрудитов. Но с приходом LLM (наконец-то я закончил с контекстом и перехожу к сути) у них появился сильнейший конкурент. Теперь LLM позволяет реализовать поиск готовых частных решений. Да, в некоторых пределах и интеллектуальные задачи могут быть решены, но эта сторона гораздо слабее (пока не достигли AGI). Т.е. люди-cpu получают гораздо больший буст и наступает эра интеллектуалов. Рутинные задачи постепенно можно конвертировать в скиллы и браться за новые вызовы.


    1. vladimirdyakov Автор
      25.05.2026 07:41

      Интересное наблюдение


  1. unitcraft
    25.05.2026 07:41

    Согласен в общем, но добавлю — есть третий режим, кроме «работает за вас» и «работает с вами»: «работает по плану-контракту». У меня за месяц 125 инженерных планов закрыто агентами полностью автономно — без моего ежедневного участия. Не «AI пишет код за тебя», а «AI исполняет план который ты написал».

    Отличие от вашего «работает с вами» — отделение проектирования от исполнения. Я думаю над планом и критериями приёмки (час), агент исполняет (30–60 минут реальной работы), я ревьюю результат (5–15 минут). Это другой коэффициент масштабирования.

    Главный риск этой модели — агент уверенно ошибается в системных допущениях. Защита — отдельный агент-критик с обратным углом, проверяет допущения, а не код.


    1. vladimirdyakov Автор
      25.05.2026 07:41

      У меня, сожалению, в таком режиме слишком много переделывать приходится. Возможно, ваш подход работает для проектов до определеной сложности и неопределенности.


      1. unitcraft
        25.05.2026 07:41

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

        Где у меня работает: задачи, где можно жёстко описать «было/стало» через тесты или конкретный результат. Архитектурные решения принимаю сам (157 решений за месяц зафиксированы вручную), агентам отдаю только исполнение — реализуй фичу X в файле Y, чтобы тесты Z прошли, без регрессии остального.

        Когда план невозможно описать ясно — да, не пытаюсь автономно. Тогда прототип сначала рукой, потом план уже на основе понимания.


        1. vladimirdyakov Автор
          25.05.2026 07:41

          Похоже, что наш опыт сходится


          1. unitcraft
            25.05.2026 07:41

            Похоже что так. У меня «план как контракт» работает на узкой полосе задач (повторяемая инженерия с явными тестами), твой «работает с вами» — шире и универсальнее. Спасибо за хорошую дискуссию.


            1. vladimirdyakov Автор
              25.05.2026 07:41

              Взаимно!