Using coding assistance tools to revive projects you never were going to finish
У каждого из нас есть такой цифровой «цыганский табор» — проекты, которые мы когда-то начали с огромным энтузиазмом, а потом забросили. Лежат себе в репозиториях, пылятся, ждут своего часа. Который никогда не наступит.
Японцы даже придумали слово для这种现象 — тсундоку: книжная полка с книгами, которые вы планировали прочитать «когда-нибудь». У программистов та же история, только вместо книг — код.
И вот что интересно: автор статьи, Мэтью Брунелле, задал себе вопрос, который меня давно мучает. А что если эти заброшенные проекты — идеальные кандидаты для AI-ассистентов? Всё равно они никогда не будут готовы. Так почему бы не дать искусственному интеллекту шанс?
Проект, который не ждал
Идея родилась из личной боли. Автор несколько лет назад пытался сделать «прокладку» между YouTube Music и OpenSubsonic API. Зачем? OpenSubsonic — это открытый стандарт, который позволяет разделить клиент и сервер для стриминга музыки. То есть вы можете использовать любой клиент (Navidrome, Feishin, Symfonium) с любым сервером. Свобода выбора, понимаешь?
Но тогда не хватило времени. Сначала сделал базовую рабочую версию, а потом появились другие проекты и увели в сторону. Знакомо? Мне — очень.
Проект пылился. Пока автор не решил: а дай-ка я проверю, на что способен Claude Code (AI-ассистент для написания кода от Anthropic). Заодно и посмотреть, как инструменты эволюционировали.
Подготовка: меньше — лучше
Автор не стал кормить ИИ всем подряд. Наоборот — он сознательно ограничил контекст. Создал проект через uv (менеджер пакетов для Python), добавил зависимости: FastAPI (веб-фреймворк), Pydantic (для валидации данных), ytmusicapi и yt-dlp (инструменты для работы с YouTube Music). Положил в папку спецификацию OpenSubsonic API и написал краткое описание в README.
Но главное — он сгенерировал файл CLAUDE.md. Это такая инструкция для AI-ассистента: какие конвенции использовать, какой стиль кода предпочитает автор. Например:
- Методы должны иметь аннотации типов и docstrings (документацию)
- Использовать Pydantic V2
- Docstrings в формате Google
- Тесты через pytest с современным стилем
По сути, это набор правил, которые не нужно повторять каждый раз. Умно, правда?
Как это работает: workflow
Автор описал свой типичный процесс работы с AI-ассистентом:
РАБОЧИЙ ПРОЦЕСС С AI-АССИСТЕНТОМ
─────────────────────────────────
Вход в план-режим → Описание задачи → Проверка плана
↑ │
│ "Accept and clear context" │
└──────────────────────────────────────────────┘
- Входишь в план-режим — просишь ИИ составить план
- Пromptишь следующий кусок работы
- Проверяешь план на предмет пробелов, задаёшь уточняющие вопросы
- Сбрасываешь контекст («Accept and clear context») и повторяешь
Первый запрос был простым: «Посмотри на спецификацию OpenSubsonic и сделай заглушки (stubs) для всех методов». Stub — это такая «заглушка», упрощённая реализация, которая ничего толком не делает, но сигнатуру метода возвращает правильную.
Потом — следующий этап: «Соедини клиент с сервером, сделай поиск и стриминг». И так далее.
Результат: удивительно быстро
Автор признаётся: он был шокирован. После пары итераций аудио реально пошло через клиент Feishin. Основные грабли — заглушки возвращали пустоту, нужно было правильно структурировать ответы.
Для минимально жизнеспособного продукта (MVP — минимальный набор функций, чтобы вообще работало) понадобилось реализовать:
- getLicense, getUser, getGenres, getMusicDirectories — базовые методы
- search3 — поиск через ytmusicapi
- stream — стриминг через yt-dlp
- getCoverArt — обложка альбома
А потом — долгий хвост. Кэширование запросов (чтобы не упираться в лимиты YouTube). SQLite база для метаданных. Реализация всех 80 эндпоинтов из 15 категорий. Обработка обрыва соединения (удалять недокачанные файлы).
Всё это автор «вручную» делать не стал бы никогда. Но AI сделал. За один вечер.
А теперь — философский вопрос
Вот что меня зацепило больше всего. Автор задаётся вопросом: это вообще хорошо?
Он признаётся, что у него есть страх «deskilling» — потери навыков от чрезмерного reliance на AI. Поэтому он продолжает учить Rust (язык программирования, непростой для изучения), делает «растягивающие» проекты.
Но он предлагает интересную типологию:
ДВА ТИПА ПРОЕКТОВ ───────────────── [ Проекты для обучения ] ← Ты делаешь, чтобы расти [ Проекты "хочу чтобы ] ← Ты делаешь, чтобы получить [ это существовало" ] ← результат, инструмент нужен
Проекты второго типа — идеальные кандидаты для AI-ассистентов. Всё равно ты не стал бы их делать сам. Но теперь они могут появиться. Один «тсундоку» меньше на книжной полке.
Моё мнение
Меня эта статья зацепила, потому что она честная. Нет восторженного «AI спасёт мир!» и нет панического «AI убивает программистов». Есть понимание, что инструмент — инструмент. Важно только не забывать, для чего ты учишься, а для чего — просто хочешь результат.
У меня самого пара таких проектов лежит. Может, и правда пора дать им второй шанс?
#
idea ──▶ draft ──▶ review ──▶ publish
Ссылки
Дмитрий Полухин — продуктовый дизайнер. Пишу про разработку, AI и дизайн интерфейсов. Обо мне, контакты и профили.