← Блог

Как я начал строить Personal OS с аудита проектов

Сережа Рис · 11 February 2026

claude codeпаттерны

Чтобы построить Personal OS, нужно сначала понять, что у тебя уже есть. Я попросил двух агентов параллельно проанализировать ~10 активных проектов. За вечер они нашли 8 повторяющихся сервисов — логику, которую я переписывал заново в каждом проекте, не замечая этого. Оказалось, что мой Personal OS уже наполовину собран — просто разбросан по папкам.

Идея: корпорация на ноутбуке

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

Сейчас это зоопарк. Каждый проект живёт отдельно, каждый решает свою задачу. Но идея Personal OS — превратить зоопарк в корпорацию. Общие сервисы, которые все проекты используют. Сначала локально, на моём ноутбуке. Когда всё заработает — вынести на сервер.

Но прежде чем строить — нужно понять, что из этого уже существует.

Невидимый налог

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

По данным CodeAnt.ai, 20% кода в корпоративных кодбазах — дубликаты. У соло-разработчиков, подозреваю, больше. Потому что некому сказать: “Стоп, это уже есть в другом проекте.”

Невидимая копипаста — каждый проект в своей папке, своём репозитории, со своим контекстом. И ты не замечаешь, что решаешь одну задачу четвёртый раз.

Момент

Я готовил инвентаризацию контент-экосистемы — документировал, что к чему подключено, какие сервисы и инструменты используются. Смотрел на проекты сверху.

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

Метод: два агента, один вечер

Запустил два Explore-агента параллельно через Claude Code. Каждый со своим фокусом — один на обработку текстов, другой на инфраструктурные паттерны.

Первому агенту (Claude Code, Opus 4.6):

Проанализируй эти проекты [список путей]. Найди повторяющуюся логику обработки текстов: chunking, summarization, extraction. Покажи конкретные реализации — где одно и то же сделано по-разному.

Второму — параллельно:

Посмотри на инфраструктурные паттерны в тех же проектах. Как выбирается LLM-модель? Как устроена доставка сообщений? Есть ли общие подходы к scoring и ранжированию?

Через несколько минут — результаты. Восемь повторяющихся сервисов в десяти проектах. Восемь готовых кирпичей для Personal OS, которые я уже построил — просто не знал об этом.

Не буду разбирать все восемь — статья не обзор. Покажу три самых жирных. Те, которые повторялись в 4-6 проектах каждый.

Сервис 1: Разбиение текста на части

Четыре проекта. Четыре реализации одного и того же.

Генератор дайджестов режет чат на куски по предложениям. Конвертер видео — по таймкодам с перекрытием. Поисковик по переписке — по фиксированным 500 символов. Платформа для учеников — по смысловой близости через эмбеддинги (векторные представления текста).

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

Сервис 2: Двухэтапный пайплайн

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

Я уже писал про это на примере одного бота. Но не понимал масштаб. Тот же подход — в генераторе дайджестов, в конвертере видео, в платформе для учеников, в пайплайне для статей, в инструменте деаификации текста.

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

Сервис 3: Выбор модели под задачу

Каждый проект решает заново: какую модель вызвать? Flash для извлечения, Pro для генерации, Whisper для транскрипции, Haiku для превью.

Нет единого места, где записано: “для extraction — используй вот это, для generation — вот это”. Каждый проект хранит эти решения в своём коде. Обновил модель в одном — забыл в четырёх остальных.

Это связано с тем, как я работаю. Как и у многих вайбкодеров, каждый проект — это отдельный агентский контекст. Агент знает только про свой проект. Он не видит, что в соседней папке уже есть решение.

Как они связаны

┌──────────┐     ┌──────────┐     ┌──────────┐
│  Выбор   │────▶│Двухэтапн.│────▶│ Разбиение│
│  модели  │     │ пайплайн │     │  текста  │
└──────────┘     └────┬─────┘     └──────────┘
 Какую модель         │            Как подготовить
 для какого           │            текст для LLM
 этапа?               │
                      ▼
                ┌──────────┐
                │ Scoring  │
                │ контента │
                └────┬─────┘
                     │ Что важнее?
                     ▼
                ┌──────────┐
                │ Доставка │
                │ результата│
                └──────────┘

Выбор модели определяет, как работает пайплайн. Пайплайн определяет, как разбивается текст. Scoring определяет, что доставлять.

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

Что с этим делать

После аудита я не побежал всё рефакторить. Это было бы преждевременно — Дейв Фарли предупреждает, что чрезмерное переиспользование между сервисами создаёт связанность. Вытащишь chunking в общую библиотеку — и каждое обновление ломает пять проектов.

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

По-моему, это тот же паттерн “правка → правило”, только на уровне выше: увидел повторение между проектами — зафиксировал. Не обязательно сразу автоматизировать.

Следующий шаг — вытащить самые зрелые сервисы в общие модули. Сначала локально, чтобы убедиться, что всё работает. Потом — на сервер. Корпорация на ноутбуке, которая однажды переедет в облако.

Попробуй сам

Вот промпт для Claude Code (или любого агента с доступом к файлам):

Проанализируй проекты в [перечисли папки]. Найди повторяющуюся логику — код или подходы, которые реализованы больше одного раза. Для каждого паттерна покажи: где встречается, чем отличаются реализации, и можно ли их объединить в одну. Результат — таблица: паттерн, проекты, уровень дублирования.

Если проектов больше 5 — разбей на два параллельных агента с разным фокусом. Один ищет бизнес-логику, другой — инфраструктуру. Результаты потом легко объединить.

По данным RDW Software Engineering, после извлечения переиспользуемых сервисов в реальном проекте дублирование снизилось на 38%, а переиспользование выросло на 33%. Компания Cyrus показала, что 6 AI-агентов за 3.5 часа справились с аудитом, на который у senior-инженера ушло бы 2-3 недели.

Частые вопросы

Нужно ли сразу рефакторить?

Нет. Аудит — это карта, а не план действий. Зафиксируй находки, используй при следующем проекте. Выделение сервиса оправдано, когда одна и та же логика мешает жить в 3+ проектах.

Это работает только с Claude Code?

Нет. Любой агент с доступом к файловой системе — Cursor, Windsurf, даже ChatGPT с Code Interpreter и загруженным кодом. Суть в промпте, не в инструменте.

А если проекты на разных языках?

Паттерны живут на уровне архитектуры, не синтаксиса. Двухэтапный пайплайн одинаково работает в Python-боте и в TypeScript-сервисе. Агент это увидит.

Читайте также

Об авторе

Подписаться на обновления — @sereja_tech