Кажется, главный риск здесь даже не Bearer/scopes, а то, что новый /api/* endpoint может автоматически стать agent-callable. Как вы это контролируете: deny-by-default через route metadata/capability registry или blacklist для UI-only handlers?
И второй момент: generic invocation для большого числа endpoints не размывает модель прав? Для write-операций вроде start/approve, наверное, безопаснее явно описывать tool schema и scopes для каждого действия.
Хороший акцент на том, что при конфликте часто не нужно выбирать “нашу” или “их” версию, а нужно собрать третий вариант. Это, по-моему, самая важная мысль для новичков.
Я бы только добавил в общий алгоритм один обязательный шаг перед редактированием файла: сначала посмотреть git status и понять, какая операция сейчас находится в процессе: merge, rebase или cherry-pick. От этого зависит не только команда продолжения, но и то, как интерпретировать стороны конфликта.
Особенно это важно при rebase: ours/theirs там часто воспринимаются не так, как ожидает человек, который привык к обычному merge. Поэтому в сомнительных случаях безопаснее не жать “accept current/incoming” на автомате, а посмотреть стадии индекса:
git show :1:path/to/file
git show :2:path/to/file
git show :3:path/to/file
И уже после этого решать, что должно попасть в итоговый файл.
Ещё полезная привычка после ручного разрешения: перед --continue прогонять хотя бы git diff --check и тесты/линтер, если они есть. Это быстро ловит оставшиеся conflict markers и мелкие синтаксические ошибки.
Хороший материал, особенно ценно, что есть не только смета, но и сырые прогоны.
Я бы, наверное, отдельно вынес в бенчах влияние межкарточного обмена. Для 2×V100 без NVLink результат сильно зависит не только от суммарных 64 ГБ VRAM, но и от того, как конкретный стек раскладывает модель: tensor parallel, pipeline parallel, offload, частота синхронизаций между GPU и размер контекста.
На consumer-платформе x8/x8 по PCIe это может быть почти незаметно для одних сценариев и очень больно для других. Было бы интересно увидеть рядом с tokens/s ещё:
вывод nvidia-smi topo -m;
PCIe generation / lanes для каждой карты;
P2P bandwidth/latency test;
сравнение одной и той же модели, если она помещается: 1×V100 vs 2×V100 TP=2;
отдельный прогон на длинном контексте, где обмен между картами может проявиться сильнее.
Тогда статья закрывала бы не только вопрос “можно ли собрать 64 ГБ VRAM за 200к”, но и более практичный вопрос: где именно 2×V100 без NVLink остаётся выгодным решением, а где уже лучше смотреть в сторону SXM2/NVLink или другой архитектуры.
Я бы формулировал чуть иначе: рынок очищается не от “случайных людей”, а от иллюзии, что низкий порог входа равен низкой цене профессии.
Раньше можно было попасть в разработку через набор прикладных навыков: фреймворк, CRUD, немного верстки, немного API. Сейчас эту зону сильно сжали ИИ, шаблоны и более продуктивные опытные разработчики.
Поэтому вход в IT не исчез, но стал честнее: платят уже не за сам факт умения писать код, а за способность понимать систему, доводить задачу до результата и отвечать за последствия. Это менее романтично, зато больше похоже на инженерную профессию.
Да, в таком режиме dry-run уже может казаться лишним, особенно если контур внутренний, сервисы знакомые и есть нормальные тесты/rollback.
Я скорее про baseline для людей, которые только начинают тащить MCP в рабочую инфраструктуру: отдельный токен под MCP, read-only по умолчанию, явный список toolsets и хотя бы показ diff перед изменением конфигов. Это не сильно тормозит, но резко снижает шанс случайно поправить не тот GitLab, не тот MCP-конфиг или не тот project-level файл.
Хороший практический разбор. Самое полезное, на мой взгляд, наблюдение про layer split: много GPU даёт возможность запустить модель крупнее, но не превращается автоматически в рост tokens/sec, особенно если шина между картами не серверного уровня. Для агентского кодинга я бы ещё отдельно мерил не только скорость чтения/генерации, а time-to-useful-diff: сколько времени проходит от постановки задачи до рабочего изменения в репозитории. Там важны не только t/s, но и prefill на большом контексте, устойчивость tool calling, поведение на повторных правках и способность нормально чинить ошибки после тестов. Было бы интересно увидеть такой тест: один и тот же небольшой проект, одна задача, прогон тестов, потом просьба исправить failing test. И сравнить Qwen3.6-27B, Qwen3.6-35B-A3B и Qwen3.5-122B-A10B не по синтетике, а по тому, кто быстрее доводит diff до состояния “можно коммитить”.
Полезный чеклист, особенно про read-only режим и единый установленный MCP вместо npx в каждом клиенте.
Я бы только осторожнее относился к идее “дать AI-системе и сказать делай”. В MCP-конфигах быстро появляются токены, symlink-и, user-level и project-level настройки, и агент может случайно поправить не тот файл. Мне кажется, безопаснее начинать с dry-run: сначала найти конфиги, показать diff и только потом применять изменения.
Ещё добавил бы отдельный machine/user token под MCP, а не личный основной PAT. Так проще ограничивать scopes и потом разбирать audit trail.
Заметил одну особенность - перед выпуском новой модели Claude занижает возможности моделей и очень сильно повышает расход токенов. Но при выходе новых моделей токены становятся чуть ли не бесконечными. Полагаю, это занижение связано для того, чтобы было с чем сравнивать, иначе разница будет не столь заметной.
Кажется, главный риск здесь даже не Bearer/scopes, а то, что новый /api/* endpoint может автоматически стать agent-callable. Как вы это контролируете: deny-by-default через route metadata/capability registry или blacklist для UI-only handlers?
И второй момент: generic invocation для большого числа endpoints не размывает модель прав? Для write-операций вроде start/approve, наверное, безопаснее явно описывать tool schema и scopes для каждого действия.
Хороший акцент на том, что при конфликте часто не нужно выбирать “нашу” или “их” версию, а нужно собрать третий вариант. Это, по-моему, самая важная мысль для новичков.
Я бы только добавил в общий алгоритм один обязательный шаг перед редактированием файла: сначала посмотреть
git statusи понять, какая операция сейчас находится в процессе: merge, rebase или cherry-pick. От этого зависит не только команда продолжения, но и то, как интерпретировать стороны конфликта.Особенно это важно при rebase:
ours/theirsтам часто воспринимаются не так, как ожидает человек, который привык к обычному merge. Поэтому в сомнительных случаях безопаснее не жать “accept current/incoming” на автомате, а посмотреть стадии индекса:git show :1:path/to/filegit show :2:path/to/filegit show :3:path/to/fileИ уже после этого решать, что должно попасть в итоговый файл.
Ещё полезная привычка после ручного разрешения: перед
--continueпрогонять хотя быgit diff --checkи тесты/линтер, если они есть. Это быстро ловит оставшиеся conflict markers и мелкие синтаксические ошибки.Хороший материал, особенно ценно, что есть не только смета, но и сырые прогоны.
Я бы, наверное, отдельно вынес в бенчах влияние межкарточного обмена. Для 2×V100 без NVLink результат сильно зависит не только от суммарных 64 ГБ VRAM, но и от того, как конкретный стек раскладывает модель: tensor parallel, pipeline parallel, offload, частота синхронизаций между GPU и размер контекста.
На consumer-платформе x8/x8 по PCIe это может быть почти незаметно для одних сценариев и очень больно для других. Было бы интересно увидеть рядом с tokens/s ещё:
вывод
nvidia-smi topo -m;PCIe generation / lanes для каждой карты;
P2P bandwidth/latency test;
сравнение одной и той же модели, если она помещается: 1×V100 vs 2×V100 TP=2;
отдельный прогон на длинном контексте, где обмен между картами может проявиться сильнее.
Тогда статья закрывала бы не только вопрос “можно ли собрать 64 ГБ VRAM за 200к”, но и более практичный вопрос: где именно 2×V100 без NVLink остаётся выгодным решением, а где уже лучше смотреть в сторону SXM2/NVLink или другой архитектуры.
Я бы формулировал чуть иначе: рынок очищается не от “случайных людей”, а от иллюзии, что низкий порог входа равен низкой цене профессии.
Раньше можно было попасть в разработку через набор прикладных навыков: фреймворк, CRUD, немного верстки, немного API. Сейчас эту зону сильно сжали ИИ, шаблоны и более продуктивные опытные разработчики.
Поэтому вход в IT не исчез, но стал честнее: платят уже не за сам факт умения писать код, а за способность понимать систему, доводить задачу до результата и отвечать за последствия. Это менее романтично, зато больше похоже на инженерную профессию.
Да, в таком режиме dry-run уже может казаться лишним, особенно если контур внутренний, сервисы знакомые и есть нормальные тесты/rollback.
Я скорее про baseline для людей, которые только начинают тащить MCP в рабочую инфраструктуру: отдельный токен под MCP, read-only по умолчанию, явный список toolsets и хотя бы показ diff перед изменением конфигов. Это не сильно тормозит, но резко снижает шанс случайно поправить не тот GitLab, не тот MCP-конфиг или не тот project-level файл.
Хороший практический разбор. Самое полезное, на мой взгляд, наблюдение про layer split: много GPU даёт возможность запустить модель крупнее, но не превращается автоматически в рост tokens/sec, особенно если шина между картами не серверного уровня. Для агентского кодинга я бы ещё отдельно мерил не только скорость чтения/генерации, а time-to-useful-diff: сколько времени проходит от постановки задачи до рабочего изменения в репозитории. Там важны не только t/s, но и prefill на большом контексте, устойчивость tool calling, поведение на повторных правках и способность нормально чинить ошибки после тестов. Было бы интересно увидеть такой тест: один и тот же небольшой проект, одна задача, прогон тестов, потом просьба исправить failing test. И сравнить Qwen3.6-27B, Qwen3.6-35B-A3B и Qwen3.5-122B-A10B не по синтетике, а по тому, кто быстрее доводит diff до состояния “можно коммитить”.
Полезный чеклист, особенно про read-only режим и единый установленный MCP вместо npx в каждом клиенте.
Я бы только осторожнее относился к идее “дать AI-системе и сказать делай”. В MCP-конфигах быстро появляются токены, symlink-и, user-level и project-level настройки, и агент может случайно поправить не тот файл. Мне кажется, безопаснее начинать с dry-run: сначала найти конфиги, показать diff и только потом применять изменения.
Ещё добавил бы отдельный machine/user token под MCP, а не личный основной PAT. Так проще ограничивать scopes и потом разбирать audit trail.
Заметил одну особенность - перед выпуском новой модели Claude занижает возможности моделей и очень сильно повышает расход токенов. Но при выходе новых моделей токены становятся чуть ли не бесконечными. Полагаю, это занижение связано для того, чтобы было с чем сравнивать, иначе разница будет не столь заметной.