Скрытые налоги локального ИИ
Если вам нужна инструкция, а не эссе. Вся настройка, о которой идёт речь в этой серии, расписана по шагам в отдельном гайде — то же самое, но как процедура, которую можно выполнить, а не рассуждение, которое надо прочитать.
Первая часть была о том, до чего ИИ-агенты на моём ноутбуке дотягиваются по умолчанию, и о том, как обернуть каждый проект в dev-контейнер, чтобы то, что я не хочу отдавать, там просто отсутствовало. Эта часть — счёт за это.
Короткий пересказ для тех, кто попал сюда первым делом. Я не инженер. Последние полтора года я строю настоящие вещи с кодинг-агентами, на своей машине, для своих проектов. Я посмотрела много YouTube и прочитала много руководств на эту тему, и почти все они заканчиваются ровно в тот момент, когда настройка начинает работать. Про месяцы после — что ломается, от чего ломается, от чего вы тихо отказались — я нигде не читала, поэтому пишу сама.
Что контейнер даёт мне, а больше ничто не даёт
Начну с плюса, потому что ради него я и терплю всё описанное ниже, и потому что это не тот плюс, который обычно рекламируют.
Контейнер — это способ получить подробную историю разговоров, привязанную к конкретному проекту. Каждая сессия внутри проекта выгружается и складывается в архив под именем этого проекта, так что спустя месяцы у меня есть корпус материала, который про эту кодовую базу: решения, тупики, рассуждения, которые иначе пришлось бы восстанавливать заново.
Настольные приложения так не умеют. Они дают мою историю: один длинный неразделённый поток всего, что я когда-либо обсуждала, в порядке обсуждения. Для одного проекта это нормально. Когда работа размазана по пяти, разница между «моей историей» и «историей этого проекта» и есть всё, и отдавать это обратно мне хотелось бы меньше всего.
Счёт
Конфигурация ломается время от времени и всегда не вовремя. Обычно после обновления расширения редактора: не проходит пересборка, CLI пропадает из PATH, не поднимается подключение, что-то работавшее в пятницу не работает в понедельник. Ничего драматичного. И всё это приходит в тот момент, когда вы собирались заняться другим.
Поэтому у меня есть отдельный проект, единственная задача которого — эта самая настройка. В нём лежат шаблоны контейнеров, установочный скрипт, решения и почему каждое принято, эксплуатационные заметки и журнал всех поломок с их починками. Когда что-то ломается, я открываю этот проект, и агент, работающий там, уже знает всю историю моей конфигурации, а не гадает по стектрейсу. Звучит как многовато церемоний ради «пары файлов конфига» — и это не так: настройка это система, её сносит, и пока я не записала всё это, я раз за разом решала одни и те же поломки с нуля, плохо, в десять вечера.
Это идея памяти из третьей части, применённая к тому, на чём держится всё остальное. И это же, пожалуй, самая переносимая часть моей настройки для того, кто не инженер: среда — это проект, значит, дайте ей память проекта.
Пересборки редки, и это одновременно хорошо и ловушка. Машина у меня почти всегда включена, так что контейнеры живут неделями. Я пересобираю, только когда что-то по-настоящему сломалось или кончилась память. Значит, в промежутке конфигурация тихо расходится с задуманным, и пересборка — это момент, когда вы обнаруживаете всё накопившееся разом. Обычно тогда, когда исследовательский проект вам нужен меньше всего.
А история, которую вы храните, — не та история, которую можно читать. Всё сохраняется дословно, но в базу данных. По ней можно искать, её нельзя читать. Я не могу её пролистать. В настольном приложении я открываю разговор с прошлого вторника и листаю его как документ, схватываю форму, узнаю́ то, что помню наполовину, вместо того чтобы описывать это словами. В моей же настройке есть хранилище, которое ответит на вопрос про прошлый вторник, если я хорошо сформулирую вопрос.
Это правда разные возможности, и я выбрала ту, где есть поиск. В большинстве дней это верный размен. В некоторые дни мне нужно перечитать, а не найти, и я не могу, и я это чувствую.
Контейнер я всё равно выберу снова. Но «безопасно, и вот чего это вам стоит» — более честная подача, чем та, которую мне обычно предлагают.
То, что я нашла на прошлой неделе и что изменило мой день
Оба инструмента теперь умеют удалённо управлять запущенной сессией, в том числе сессией внутри контейнера. У Claude это работает: я могу подхватить живую сессию с телефона, ответить на запрос разрешения, продвинуть дело, пока меня нет за столом. После месяцев физической привязки к машине, где крутится контейнер, это самое заметное улучшение качества жизни за долгое время — и наткнулась я на него более или менее случайно.
Две оговорки, чтобы никто не перестраивал под это неделю. Это удалённое управление, а не сессия, которая вас переживает: сессия по-прежнему живёт и умирает вместе с контейнером, так что ноутбук от этого сервером не становится. И у второго агента есть аналог, который я не завела: он всё время отваливается. Лучшая догадка по моим же заметкам — его удалённый демон ждёт отдельной установки и отказывается работать с бинарником из расширения редактора, который на самом деле стоит у меня в контейнере. Это ровно объяснило бы поведение. Не подтверждено, лежит в списке.
Мостик, благодаря которому всё остальное выжило
Контейнеры не дотягиваются до центра уведомлений ноутбука, так что какое-то время я сидела и смотрела в терминал, чтобы не пропустить запрос разрешения, — а это неплохо обесценивает саму идею что-то делегировать. Теперь небольшой мостик на стороне хоста превращает события контейнера в обычные уведомления: агент просит разрешение, ноутбук пингует, я отвечаю, он продолжает.
Мелочь — и именно из-за неё вся эта настройка пережила столкновение с обычной рабочей неделей. Чаще всего безопасная настройка проваливается не из-за изъяна в замысле, а из-за десяти секунд трения, повторённых сорок раз за день, пока вы тихо не бросите.
Правило, которое я выучила, поставив мостик дважды: ровно один слой хуков на продукт. Оба инструмента складывают определения хуков с пользовательского уровня и с уровня проекта, так что если настроить оба, каждое событие срабатывает дважды. Безвредно и доводит до белого каления, а на то, чтобы понять, почему ноутбук пингует по два раза, у меня ушло больше времени, чем хотелось бы признавать.
Переезд на сервер, который я отложила намеренно
План был перенести всё — контейнеры, хранилище памяти, вычисления — на небольшой сервер, доступный откуда угодно через частную mesh-сеть. Доступ с телефона для меня обязателен, и это отсекло несколько в остальном хороших вариантов. На бумаге всё выигрывает: вычислений больше, чем у ноутбука, наружу ничего не торчит, ноутбук перестаёт греться.
Отложить меня заставили две вещи.
Я неправильно сравнивала размеры. Я сопоставляла кандидата в серверы со всем своим ноутбуком — пока не заметила, что Docker на нём и так ограничен шестью гигабайтами оперативной памяти. Относительно этой реальной базы (не характеристик ноутбука, а настоящего потолка, который вообще видят мои контейнеры) коробка примерно за 20 долларов в месяц уже перекрывает то, что я использую. Полезно выяснить до того, как подписываешься на вчетверо дороже.
«Всё же в git, зачем тогда изолировать?» Я приводила себе этот довод, и это ошибка категории. Git делает плохие правки обратимыми. Он ничего не делает с ключом, утёкшим из файла окружения другого проекта, с изменением в живой базе, которая не под версионным контролем, или с исходящим запросом, который уже случился. Ровно для таких провалов изоляция и существует. А если сложить все проекты на одну общую машину, где из любой сессии доступны все учётные данные, база и ключи для выкладки, радиус поражения станет больше нынешнего, а не меньше. Если я и перееду, контейнеры по проектам переедут со мной.
Есть ещё кусок, который я не проверила. Отчасти я держу столько контейнеров вовсе не ради безопасности: моя работа с памятью выводит имя проекта из рабочего каталога, и один контейнер на проект оказался удобным способом всё разделить. Это особенность инструментов, а не требование, и я пока не знаю, переживёт ли разделение отказ от контейнерной границы. Пока не проверю, решений поверх этого принимать не буду.
Что мне хотелось бы, чтобы отсюда унесли
Контейнер не бесплатный. Он стоит регулярного налога на обслуживание, изредка вечера и одной возможности, по которой я правда скучаю. Взамен он даёт структурную безопасность и историю по каждому проекту, и для меня этот размен явно выгоден — но пусть человек выбирает, видя оба столбца.
А налог на обслуживание — как раз та часть, которую можно спроектировать так, чтобы её не было. Не упрощая настройку, а дав ей память: запишите, что вы настроили и зачем, ведите журнал того, что сломалось и что помогло, — и следующая поломка будет стоить двадцати минут вместо вечера.
Об этом третья часть, где та же мысль применяется уже к самим проектам — и где я дважды ошиблась, прежде чем сделать правильно.
← Рабочая среда не-инженера, часть первая — безопасность · Рабочая среда не-инженера, часть третья — память →