Продолжаю размышлять о том как работать в условиях, когда ИИ бурно развивается. Сегодня решил поговорить о том, как архитектура программного обеспечения помогает при создании ИИ агентов и новых проектов.
YouTube | VK | RuTube

Сделал видео по созданию промптов, идея была в том, чтобы рассмотреть разные варианты текстов и выделить общие правила, которые опубликовать на 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% уже вышли на уровень постоянного выгорания.

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

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

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