Сделал видео по созданию промптов, идея была в том, чтобы рассмотреть разные варианты текстов и выделить общие правила, которые опубликовать на soerdev.space в картах знаний.

В итоге получилось очень плотное информативное видео, смотреть можно тут:
YouTube | Vk | RuTube

Последнее видео по промпт-инженерии далось с особой болью, раньше я бездумно использовал советы из интернета, которые определяли, что нормальный промпт - это когда ты задаешь роль, контекст, задачу, пример (строго в таком порядке) и добавляешь конкретные измеряемые критерии качества.

Я использовал и мне казалось, что "Вау! Это работает". А потом я решил сделать ролик в котором показать "плохие" и "хорошие" промпты.

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

А знаменитое "представь что ты программист" оказалась не такой полезной штукой, как я думал.

Два варианта. Один выбор.

Допустим, у нас есть задача реализовать user story:

Как пользователь платформы, я хочу начать урок, чтобы продолжить обучение и потратить накопленные токены.

Наивная реализация на TypeScript + NestJS могла бы выглядеть как-то так:

async startLesson(userId: string, lessonId: string) {
    const user = await this.userRepository.findById(userId)
    const lesson = await this.lessonRepository.findById(lessonId)
    
    const subscription = await this.subscriptionRepository.findActiveByUser(userId)
    if (!subscription || subscription.expiresAt < new Date()) {
        throw new Error("No active subscription")
    }
    
    if (user.tokens < lesson.tokensCost) {
        throw new Error("Not enough tokens")
    }
    
    await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost })
    await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
    await this.analyticsService.track("lesson_started", { userId, lessonId })
}

Код рабочий и простой. Но насколько он хорош? Остановитесь на секунду и назовите 2-3 потенциальные проблемы этого кода. Я нашел сразу пять:

- Проверка подписки здесь, хотя должна быть в отдельном слое доступа.
- Списание токенов не атомарное - между проверкой и обновлением токены может списать другой запрос.
- Нет транзакции - если сервер упал между update и create, токены списались, а прогресс не создался.
- Аналитика блокирует основной поток.
- Нет уникального индекса на прогресс.

Учитывая эти моменты, можно сделать более надёжную реализацию:

async startLesson(userId: string, lessonId: string) {
    return this.unitOfWork.execute(async (uow) => {
        const user = await uow.users.findById(userId)
        const lesson = await uow.lessons.findById(lessonId)
        
        if (!user || !lesson) {
            throw new Error("User or lesson not found")
        }
        
        const accessResult = await this.accessService.checkAccess(user, lesson)
        if (!accessResult.allowed) {
            throw new Error(accessResult.reason)
        }
        
        const updateResult = await uow.users.updateOne(
            { _id: userId, tokens: { $gte: lesson.tokensCost } },
            { $inc: { tokens: -lesson.tokensCost } }
        )
        
        if (updateResult.modifiedCount === 0) {
            throw new Error("Not enough tokens")
        }
        
        return await uow.progress.create({
            userId,
            lessonId,
            status: "started",
            startedAt: new Date()
        })
    })
}

Код стал сложнее и надёжнее: транзакция, атомарность, разделение ответственности.

Но суть в том, что для небольшого проекта с десятком активных пользователей эта сложность чаще всего не нужна. Вероятность race condition стремится к нулю. Если транзакция зависнет - техподдержка поправит токены за пять минут, а вы потратили кучу времени на Unit of Work.

Стал ли код лучше? И да, и нет. Первый вариант по-прежнему остается самым читаемым, понятным и простым. Но на перспективу иметь разделение обязанностей и четкие границы между слоями - это очевидный плюс.

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

Важно помнить, что как программисты, мы всегда можем объяснить, какие проблемы есть в коде, какие опасности они создают. Но насколько эти "проблемы" реальны - сказать сложно. И никто не знает, какой выбор нужно сделать. Знаю только, что через год-два открою этот код и не вспомню, почему выбрал именно так. И, скорее всего, нужно будет объяснять новые проблемы и переписывать... Опять.

Сейчас куча проблем наложились друг на друга и получился глобальный кризис в АйТи - с одной стороны поджимает ИИ, который забирает часть привычной работы, с другой кризис найма.

Вопрос "Что делать и как быть?" волнует многих, поэтому я решил выпустить видео, которое подсвечивает возможности, которые можно использовать, чтобы в будущем не остаться без работы.

Ожидаемо, что несмотря на то, что в видео я постарался разложить все четко, многие находятся в глубоком заблуждении, что ИИ - это волшебная таблетка, которая может решить все проблемы разработки. На самом деле это не так, есть задачи, которые ИИ может решать, есть те, которые не может. Что за задачи смотрите в видео.

P.S. ниже скину разбор типовых возражений, которые разобрал в клубе SOERDEV. У нас так же недавно была встреча по проблемам, которые есть при использовании в разработке ИИ.

YouTube | VK | RuTube

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

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

Проблема в том, что циклов исправления очень много. Причем это не моя личная проблема, появился даже новый термин - "ботситтинг" - это когда человек "нянчится" с LLM, чтобы получить результат. По статистике, на такие проверки и исправления у сотрудников уходит в среднем 6.4 часа в неделю, то есть почти целый рабочий день.

Ситуация усугубляется тем, что сначала кажется, будто человек делает меньшую часть работы - просто правит результат ИИ, а потом ждет. Но на самом деле цикл довольно плотный, а сам момент "принятия решения" сильно выматывает психологически (делать рутинный код на порядок проще, чем быстро анализировать, находить проблемы, указывать, что нужно переделать).

Если посмотреть на историю коммитов, кажется, что проект растет, но если смотреть на качество - значительная часть кода - это сплошные исправления. Причем я не могу назвать это "рефакторингом".

Рефакторинг - это улучшение структуры без изменения функциональности. В моем случае каждое исправление - это изменение поведения, которое ИИ изначально реализовал неправильно.

В итоге стал замечать, что устаю от принятия решений. Даже правильнее сказать от "скорости" принятия решений. Выматывает, что нельзя ни в чем быть уверенным, нужно все проверять и перепроверять, либо рискушь скатиться в "ботшитинг".

Такое состояние называется "AI brain fry" - это когда нужно принимать бесконечные микро-решения, которые истощают когнитивные ресурсы. В результате падает КПД и возникает разрыв между тем, что я обсуждаю, и тем, что в итоге получаю.

Пишут, что ИИ не только не сокращает объем задач, но и делает работу еще более интенсивной и сложной для человека.

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

В итоге статистика удручающая: 48% разработчиков сообщают о ментальной усталости от работы с ИИ, 44% периодически чувствуют себя измотанными, а 19% уже вышли на уровень постоянного выгорания.

При этом компании, уволившие сотрудников в надежде заменить их ИИ, вынуждены нанимать их обратно, так как модели не закрывают весь цикл разработки.

Получается, я работаю не с кодом. Я работаю с системой, которая генерирует мне работу. И этой работы становится только больше.

А вы говорите "ИИ скоро всех заменит". Сильно сомневаюсь.

Отдельно хочу про "агентные циклы" (Loop Engineering) поговорить, этот термин ввел Андрей Карпаты в своих выступлениях. Это интересная механика, которую я примерно полгода назад пытался использовать в своем оркестраторе. Идея в том, чтобы не говорить ИИ, что делать конкретно, а вместо этого выстроить цикл постепенного написания и улучшения кода. Эдакий эволюционный подход.

На самом деле все, кто серьезно занимаются разработкой с помощью ИИ, рано или поздно приходят к этой идее, так как ИИ довольно специфично работает с механизмом внимания (attention) и страдает от разных "эффектов" - потеря информации в середине контекста (lost-in-the-middle), ослабление фокуса на ранних инструкциях, излишнее якорение (anchoring bias) и накопление ошибок (error accumulation), когда модель достраивает решение вокруг уже сгенерированного кода, даже если там есть проблема. Из-за этого модель может пропускать важные детали, даже если указать на них явно. При этом ИИ способен находить отклонения и ошибки если запустить его повторно. Поэтому запуская модель в цикле можно получить нормальный результат.

Но есть несколько проблем. Во-первых, большое потребление токенов. Например, средний цикл на 8-10 часов использует от 30 до 60 млн токенов. Если брать токены через API, то получается довольно дорого.

Во-вторых, в длинных циклах агент начинает "дрейфовать", постепенно уходя в сторону от поставленной задачи. Проблема в том, что критерии приемки сложно сформулировать так, чтобы они покрывали все детали - сосредоточившись на одном аспекте, упускаешь другие. Даже если проводить многоступенчатые проверки, остается проблема "2 из 3" - когда ты не можешь закрыть все требования одновременно и вынужден идти на компромисс. Чем длиннее цикл, тем сильнее этот эффект.

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

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

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

Для того чтобы погонять Fable 5, пришлось вернуть подписку на Клода. В целом чувствуется, что модель сильнее Opus 4.8 (это проявляется в мелких деталях, подробнее писал в ИИ-лаборатории нашего клуба), но глобально ничего не меняется.

Но вот что меня поразило, так это мои ощущения от использования Claude Code: как же я отвык от human in the loop, сидеть и постоянно контролировать - это не мое.

У меня сейчас для работы сделано два оркестратора. Один реализует проектный SDLC, второй - общего назначения. Они связаны друг с другом и могут обмениваться заданиями и статусом выполнения, в общем агенте есть общий чат куда прилетают отчеты о выполнении.

Развиваю проекты инкрементами, которые выглядят примерно так:

$soerdev add spec "Новая фича"
$soerdev refine spec
$soerdev plan
$soerdev run

Это реализация цикла Human ON the loop. Логика такая: добавляем драфт спеки, обсуждаем детали, фиксируем план, запускаем цикл до выполнения критериев останова. В работу не вмешиваюсь, но вижу в чате и телеграм боте что происходит.

И знаете что? Это реально удобно! Теоретически что-то подобное можно настроить и в CLI-агентах, но все равно придется допиливать харнес для отправки сообщений в телеграм, делать свой аналог гейтов, делать скилы и промпты. А так все зашито в оркестратор soerdev.

Как же больно использовать API вызовы для Fable 5. Это стата из OpenCode Zen, у меня для ревью спеки используется Fable, а для написании спеки в части программных интерфейсов Kimi 2.7, на то чтобы Fable дал несколько замечаний улетает 4-5$ (по сути это один промпт).


Другими словами - хочешь задать вопрос Fable плати 5$. Был бы я ИИ, зарабатывал бы на ответах в чате.

Закончилась эпоха

Недавно Дядюшка Боб (автор книг "Чистый код", "Чистая архитектура" и т.д.) заявил, что вообще не читает код, который пишет LLM, вместо этого он использует ограничения в виде автоматизированных тестов и других проверок. Подобных заявлений с каждым днем становится все больше и количество будет только расти.

Можно возразить, мол "а как же качество?". На самом деле за последние два года качество генерации сильно возросло, если грамотно гранулировать задачу, можно обойти многие ограничения ИИ (например, дублирование функций и классов, если их нет в контексте, и тому подобные вещи). Фокус ушел на AiSDLC и описание архитектуры проекта.

Мне кажется, в моменте мы переживаем этап взросления разработки, когда от написания кода мы уходим к архитектуре и идеям. В этом смысле Роберт Мартин не изменяет своим принципам – он всегда топил за более высокоуровневый взгляд на программирование, и теперь ему стало делать это чуть проще.

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

Поэтому код не исчезнет, просто заниматься им будут по желанию, из любопытства, а не потому что надо.

У Сбера есть интересный whitepaper где он описывает технологию разработки продукта с помощью агентных циклов.

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

Хотим мы этого или нет, но основой работы для инженеров - становится архитектура агентных циклов, умение выстраивать процессы, делать оценку качества, вносить и контролировать метрики качества.

Это работает потому что бизнесу интересно выпускать фичи в 2-3 раза быстрее, даже за счет дополнительных издержек на производство этих фич.

Некоторое время еще можно подождать, чтобы убедиться, что тренд устойчив, но, ИМХО, цикл ранних последователей уже скоро закончится.

Внимание, скам!
Появился бот который выдает себя за бота моего канала. Я НИЧЕГО ЧЕРЕЗ БОТОВ НИКОМУ НЕ ПРОДАЮ. Жалуйтесь на скам если вам прелитит предложение на скидку от бота в телеге.