Сразу разведём понятия, потому что на этом стоит вся статья.

Я больше года не пишу код руками — всё пишет ИИ. При этом я не вайбкодер. Скромно называю себя ИИ-инженером.

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

Со стороны действие одинаковое. По сути — противоположные профессии. И сейчас расскажу, почему эта разница скоро будет стоить компаниям дорого, и при чём тут git-клиент, который я написал.

С чего всё началось: консоль и ничего больше

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

Реальность такого контура: нормальный Git-клиент не поставить. Fork, GitKraken, SourceTree — блок. Логика ИБ понятна и правильна: эти клиенты проприетарные, ходят на свои зарубежные серверы, тянут телеметрию. Для закрытого контура это автоматический отказ.

Остаётся голая консоль. Я ничего не имею против git в терминале. Но когда у тебя большой проект, ветки, конфликты, история на тысячи коммитов — хочется видеть граф, а не реконструировать его в голове. Особенно когда рядом коллеги, которые жёстко вайбкодят и коммитят прямо через агента, не глядя в репозиторий. Залить код вслепую — это прям самое зло.

В какой-то момент я устал искать альтернативу и взялся писать свой клиент. Долго выбирал название, остановился на GitBor.

Что значит «пройти ИБ» технически

GitBor — десктопный Git-клиент на Electron поверх системного git. Windows и Linux, macOS в планах. Вся цель была — пройти ИБ на работе и сделать достойный аналог, который реально помогает.

Почему его в принципе можно протащить через ИБ, в отличие от зарубежных аналогов:

• Работает локально. Не ходит на внешние серверы за твоим кодом. Нет телеметрии, нет «домашних» коннектов.

• Есть сборка вообще без ИИ. Это результат того, что в мой контур не пустили версию с ИИ-надстройкой. Для самых строгих ИБ — ноль облачных функций в принципе. Чистый инструмент.

• Если ИИ нужен — только локальный. Ollama, LM Studio, любой локальный OpenAI-совместимый endpoint. Код не покидает машину.

• Российский правообладатель. Важно и для ИБ, и для Реестра.

Честно: у меня это прошло внутренний ИБ-ревью в моей компании, не более того. Я не выдаю это за сертификацию по ГОСТ или одобрение для банков. Но архитектурно продукт изначально под закрытый контур — и это то, что ИБ способна пропустить.

Ради чего я вообще пишу эту статью

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

И тут я понял, что мой клиент перестал быть просто заменой Fork. Он стал микроскопом над работой ИИ.

Я открываю GitBor и вижу не то, что ИИ сказал, что сделал, — а что он сделал на самом деле. Каждую строку. Беру по блокам только то, что проверил. Остальное отбрасываю прямо в diff. Не коммичу всё подряд — собираю осмысленный коммит из того, что реально готово.

Работаю циклично: просишь сделать функцию или компонент — и сразу смотришь в diff GitBor, куда пошёл агент. Слабые модели фигачат тонны кода и раскидывают его повсюду. В проге это хорошо видно, и главное — можно быстро надавать по рукам.

Отдельный кайф — когда часть уже работает, но боишься, что следующий промпт сломает всё. А со слабыми агентами так и бывает. Чтобы подстраховаться, закидываешь рабочий кусок в GitBor, в блок «подготовлено». По факту получаешь две версии одного файла одновременно: можешь за секунды либо принять то, что сделал агент, либо вернуть то, что было до него — без всякого отката.

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

Что внутри (коротко, по делу)

Чтобы это было не «ещё один Electron-клиент»:

• 5 уровней защиты данных: git reflog, auto-stash перед деструктивными операциями, сохранение HEAD-хеша, WAL-журнал операций, RecoveryManager при старте. Цель — чтобы потерять данные было практически невозможно.

• Worker-пул для тяжёлых парсеров: граф на тысячи коммитов раскладывается в отдельном потоке, UI не висит.

• Независимые мульти-репо движки: долгий pull на одном репозитории не блокирует операции на другом.

• 635 юнит-тестов — потому что инструменту, которому доверяют код, нельзя падать.

• Граф с виртуализацией, интерактивный rebase, diff inline/split с подсветкой, blame, двухколоночное разрешение конфликтов.

Честно о том, что не так

Раз уж пишу честно — про слабые места, а не только глянец:

• Нет code signing. На Windows вылезает SmartScreen, а на свежей Win11 со Smart App Control установка может жёстко блокироваться без обхода. Для домашних машин это реальный барьер.

• С сертификатами в РФ сейчас тяжело — западные CA не продают, а российский для SmartScreen бесполезен. Так что подпись — открытый вопрос.

• Не претендую заменить всем Fork. Я закрыл свою боль и боль коллег.

• Исходники закрытые. Это осознанный выбор, можно спорить.

Зачем эта статья

Я не продаю — GitBor, он бесплатный. Мне интереснее обсудить тезис, с которого начал: в эпоху ИИ ценность сместилась с «написать код» на «проверить, что код не врёт». Менеджеры всё чаще думают, что джун с ИИ заменяет инженера. Я думаю, счёт за эту веру придёт.

GitBor — мой способ держать этот контроль видимым. Windows и Linux, есть сборка без ИИ. Если интересно — https://gitbor.ru. Буду рад жёсткому фидбэку в комментариях, особенно от тех, кто сидит в таком же закрытом контуре.