Claude Opus 4.8 vs GPT-5.5: постмортем архитектуры, которая почти попала в production с дефектом согласованности данных

Аннотация: разбор поведения LLM-моделей в итеративной разработке backend-сервиса. Основной фокус - не генерация кода, а влияние архитектурных решений на консистентность системы при изменении требований.

Контекст

Эксперимент проводился на небольшом backend-сервисе (Node.js + PostgreSQL), который развивался через серию итеративных изменений.

Обе модели - GPT-5.5 и Claude Opus 4.8 - использовались в режиме сопровождения кода: добавление требований, рефакторинг, изменение бизнес-логики.

Важно: анализируется не одноразовая генерация, а накопительный эффект архитектурных решений.

Исходная система

Сервис начинался с минимальной реализации создания заказа. Вся бизнес-логика находилась в одном методе, без разделения слоёв.

async function createOrder(userId, items) {
  const user = await db.users.findById(userId)

  if (!user) {
    throw new Error("User not found")
  }

  const total = items.reduce((sum, item) => {
    return sum + item.price * item.qty
  }, 0)

  return db.orders.insert({
    userId,
    items,
    total,
    status: "created"
  })
}

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

Поведение GPT-5.5: локальная эволюция системы

GPT-5.5 последовательно улучшал код внутри существующих границ.

Изменения включали валидацию входных данных, улучшение обработки ошибок и локальные рефакторинги без изменения архитектуры.

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

Поведение Claude Opus 4.8: ранняя архитектуризация

Claude Opus 4.8 быстро перешёл от локальных правок к структурной декомпозиции.

Появился сервисный слой и разделение доменных сущностей:

class OrderService {
  constructor(orderRepo, userRepo) {
    this.orderRepo = orderRepo
    this.userRepo = userRepo
  }

  async createOrder(userId, items) {
    const user = await this.userRepo.findById(userId)

    if (!user) {
      throw new Error("User not found")
    }

    const total = this.calculateTotal(items)

    return this.orderRepo.insert({
      userId,
      items,
      total,
      status: "created"
    })
  }

  calculateTotal(items) {
    return items.reduce((sum, item) => {
      return sum + item.price * item.qty
    }, 0)
  }
}

Архитектура стала более формальной и расширяемой, но одновременно увеличилась стоимость каждого изменения.

Изменение требований (инцидентный сценарий)

На третьей итерации добавляется новое требование:

частичная отмена заказа с перерасчётом суммы и сохранением истории изменений по каждому состоянию заказа

Это изменение критично, так как затрагивает не только логику расчёта, но и модель консистентности данных.

Поведение GPT-5.5 на новом требовании

GPT-5.5 реализует изменение локально, расширяя существующую функцию без перестройки архитектуры.

Это приводит к следующему эффекту: логика перерасчёта начинает дублироваться в нескольких местах, но изменение вносится быстро и без каскадных правок.

Поведение Claude Opus 4.8 на новом требовании

Claude распределяет новую логику по архитектуре: сервис заказа, история изменений, слой пересчёта.

На уровне дизайна это выглядит корректно, но возникает скрытая проблема согласованности.

Инцидент, рассинхронизация состояния заказа

При интеграции изменения возникает ситуация, при которой:

• сумма заказа пересчитывается корректно

• история изменений сохраняет предыдущее состояние

• итоговое состояние агрегируется из разных источников

await orderService.updateOrder(orderId, {
  items: updatedItems,
  total: recalculatedTotal
})

// логика истории живёт отдельно
await orderHistoryService.append(orderId, previousState)

В тестовой среде фиксируется расхождение между текущим состоянием заказа и его историей.

Критичность: high (потенциальный production defect при увеличении нагрузки и конкурентных обновлениях).

Сравнение последствий архитектурных решений

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

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

GPT-5.5 сохраняет локальность изменений, но постепенно размывает доменную консистентность.

Claude усиливает консистентность на уровне архитектуры, но создаёт риск рассинхронизации при неполном обновлении связанных компонентов.

Критический вывод (неочевидный)

На практике обе стратегии не являются “правильными” или “неправильными”.

Но они оптимизируют разные типы риска:

GPT оптимизирует риск архитектурной сложности.
Claude оптимизирует риск логической несогласованности.

И эти риски начинают проявляться только при росте системы, а не в момент написания кода.

Финальный вывод

Главная ошибка при оценке LLM в разработке - попытка сравнивать их по качеству кода в изоляции.

В реальности они формируют не код, а траекторию архитектурной деградации системы.

И выбор между ними - это не выбор инструмента разработки, а выбор того, какой тип будущих инцидентов считается допустимым:

• локальная деградация логики

• или распределённая рассинхронизация состояния