Несколько месяцев назад команда PHP-разработчиков под руководством тимлида завершила создание чатбота на базе RAG-архитектуры. Система умела загружать документы из разных источников, индексировать их, хранить эмбеддинги, искать контекст с re-ranking и вести историю диалогов. Стек: Windsurf с моделью GPT-5 Low Thinking Pro, плагин OpenSpec в PHPStorm, фреймворк Yii с сильной кастомизацией. То, что раньше занимало недели обсуждений и проектирования, появилось за несколько часов.
RAG (Retrieval-Augmented Generation) — подход, при котором языковая модель перед генерацией ответа получает релевантные фрагменты из внешней базы знаний. Это позволяет отвечать на вопросы по корпоративным документам или актуальным данным, которых нет в обучающей выборке модели. Архитектура требует нескольких взаимосвязанных компонентов: пайплайна загрузки и разбивки документов, векторного хранилища для эмбеддингов, механизма поиска и ранжирования, и, наконец, самой языковой модели. Каждый из этих компонентов — отдельное инженерное решение с набором компромиссов.
Для хранения векторов модель предложила pgvector — расширение PostgreSQL, которое добавляет поддержку векторного поиска прямо в реляционную базу данных. Решение выглядело разумно: не нужна дополнительная инфраструктура, быстрое внедрение, на текущих объёмах данных всё работало. Команда приняла рекомендацию практически без обсуждений. Альтернативы — специализированные векторные движки Qdrant и Milvus — не рассматривались.
Для хранения векторов модель предложила pgvector поверх PostgreSQL; команда приняла решение без обсуждения альтернатив вроде Qdrant или Milvus.
Именно здесь тимлид обнаружил проблему. Когда он спросил разработчиков, почему выбран pgvector, а не отдельный векторный движок, в какой момент PostgreSQL перестанет справляться и как система будет масштабироваться при десятикратном росте данных — уверенных ответов не последовало. Не потому что решение было плохим. Возможно, для конкретных задач оно было оптимальным. Проблема в другом: команда не пришла к нему сама. Она приняла первую качественную рекомендацию модели и двинулась дальше.
Автор сравнивает это с шахматами: когда гроссмейстер показывает красивую комбинацию, она кажется почти очевидной. Но если убрать подсказку и дать ту же позицию без готового ответа — найти правильный ход самостоятельно оказывается принципиально сложнее. Разобраться в существующей архитектуре проще, чем придумать её с нуля. Найти слабые места в решении легче, чем предложить реальную альтернативу. Это разные виды интеллектуальной работы, требующие разных навыков.
Тимлид принял решение, которое команда встретила в штыки: переписать значительную часть проекта заново. Первая версия при этом никуда не делась — она стала рабочим прототипом, эталоном поведения системы и картой местности. Команда уже знала, какие компоненты нужны и как должен выглядеть результат. Задача переписывания состояла не в том, чтобы получить другой код, а в том, чтобы заново пройти путь принятия ключевых инженерных решений — самостоятельно, с аргументами, со спорами и с пониманием цены каждого компромисса.
Эта история отражает более широкую дискуссию в индустрии. Инструменты вроде Windsurf, Cursor и GitHub Copilot ускоряют написание кода — иногда радикально. Но скорость генерации и глубина инженерного понимания — разные метрики. Команды, которые используют ИИ как автопилот, рискуют накапливать архитектурный долг, который не виден в коде, но проявляется при первом серьёзном масштабировании или нестандартном сбое. Автор не призывает отказываться от ИИ-инструментов — напротив, он убеждён, что они пришли надолго. Но он разграничивает два режима работы: ИИ как усилитель инженера, который понимает, что и зачем делает, и ИИ как замена инженерного мышления.
