Разработчик решил проверить возможности современных локальных языковых моделей (LLM) и поставил перед ИИ задачу создать собственную систему контроля версий (VCS), функционально похожую на Git. В качестве инструмента была выбрана модель qwen3.6:27b_Q4_K_M, работающая через платформу Ollama и Open WebUI на сервере с процессором AMD Threadripper и видеокартой RX 7900 XT (с 20 ГБ видеопамяти). Цель заключалась в реализации VCS с поддержкой репозиториев, снимков состояния, хэшированием объектов по SHA-256 и историей коммитов, при этом запрещалось использовать существующий Git или обращаться к сети.
Параметры и архитектура системы контроля версий
Для создания проекта был сформирован детальный запрос. Основные требования к системе tinyvcs включали использование исключительно стандартной библиотеки Python. Нейросети предстояло реализовать поддержку команд init, commit -m, log, status и checkout. Функционал должен был обеспечивать бинарную совместимость, определение статуса файлов (добавлен, изменен, удален) и наличие родительских ссылок в коммитах. Система также должна была корректно обрабатывать ошибки при работе с поврежденными метаданными и предотвращать перезапись незафиксированных изменений в ходе команды checkout.
В задачу входило создание файлов tinyvcs.py, README.md и DEVLOG.md, а также проведение тестов: от проверки пустых и бинарных файлов до обработки имен с пробелами и вложенных директорий. Модели было предписано действовать самостоятельно, без предварительных пояснений, последовательно выполняя каждый этап до завершения проекта.
Итерации разработки и исправление ошибок
Процесс создания системы прошел через несколько этапов самопроверки и отладки со стороны qwen3.6. После первого прохода модель самостоятельно выявила ошибки в логике сравнения коммитов и очистке данных в .tinyvcs. В ходе тестирования была успешно выполнена проверка по 36 утверждениям в 14 различных сценариях. Тем не менее, во время демонстрационного коммита был обнаружен критический баг: система не блокировала checkout при наличии незафиксированных модификаций в файле, что приводило к потере данных. После получения уточняющего промпта модель успешно внесла исправления, добавила регрессионный тест и обновила журнал разработки.
Результаты работы и возможности модели
По итогам эксперимента удалось получить рабочее решение, способное выполнять базовые операции по отслеживанию изменений. Созданная tinyvcs корректно справляется с созданием репозитория, коммитами и просмотром истории. Однако проект остается лишь концептуальной базой: в нем пока отсутствуют поддержка веток, удаленных репозиториев, правил игнорирования файлов и продвинутых инструментов сравнения (diff).
Эксперимент показал, что современные локальные модели способны брать на себя полноценные задачи по написанию кода с нуля, опираясь на накопленные в публичном доступе знания. Хотя созданный продукт не заменяет полноценный Git, он подтверждает эффективность использования ИИ-агентов для быстрого создания функциональных прототипов программных инструментов.
Техническое оснащение и ограничения
Важно отметить, что выбор аппаратной конфигурации был продиктован стремлением к максимальной автономности. Использование видеокарты RX 7900 XT с 20 ГБ видеопамяти, хотя и кажется внушительным для повседневных задач, в контексте современных разработок в области ИИ является довольно скромным решением. Сервер на базе AMD Threadripper, проброшенный через LXC, обеспечил необходимую стабильность для работы модели qwen3.6:27b_Q4_K_M. Особую сложность задаче придавало полное отсутствие доступа к сети: модель не могла обращаться к внешним API, документации или уже существующим библиотекам, выходящим за рамки стандартного набора Python. Ей также было запрещено вызывать установленную в системе утилиту git — всё должно было быть реализовано «с нуля» исключительно силами кода самой модели.
Процесс разработки и взаимодействие
Взаимодействие с ИИ велось через интерфейс Open WebUI, который, по мнению автора, является наиболее подходящим инструментом для локального хостинга моделей. В ходе работы модель проявила склонность к самодиагностике. Например, после первой генерации кода она сама отметила: «Несколько проблем требуют исправления. Функция _collect_files содержит ошибку при обходе папки .tinyvcs, также некорректно работает логика сравнения коммитов». Этот процесс итеративного улучшения позволил системе пройти 36 утверждений в 14 тестовых сценариях, что подтверждалось полным отчетом по каждому выполненному тесту.
Однако без «ручного управления» не обошлось. Когда в ходе демонстрационного сценария (создание коммита А, удаление файла, переход к коммиту А, модификация файла без коммита, переход к коммиту В) был выявлен баг, приведший к потере данных, потребовалось вмешательство. Модели не удалось с первого раза самостоятельно прийти к правильной архитектуре, поэтому автору пришлось направлять её через уточняющие промпты. Основные области, потребовавшие правок: реализация _read_object(), необходимость валидации схемы содержимого деревьев, отсутствие явной обработки символических ссылок (symlinks), а также превращение DEVLOG.md из простого плана тестов в полноценный журнал разработки.
Анализ возможностей tinyvcs
После всех правок получившаяся утилита tinyvcs.py была протестирована в реальных условиях. Перенос скрипта в отдельную папку и инициализация репозитория показали, что система корректно обрабатывает создание файлов, их именование (включая имена с пробелами), обновление содержимого и фиксацию изменений. Автор отметил, что, несмотря на желание найти критические недостатки в работе самого скрипта, тот вел себя стабильно и не вызывал ошибок Python при выполнении базовых функций.
Тем не менее, функционал tinyvcs ограничен архитектурой «раннего Git». В текущем виде проект включает:
- Контентно-адресуемые объекты (content-addressed objects).
- Идентификаторы на базе SHA-256.
- Систему «блобов» для хранения содержимого файлов.
- Древовидные объекты (tree objects) для организации снимков состояния (snapshots).
На текущем этапе отсутствуют такие критически важные для профессиональной работы инструменты, как ветки (branches), удаленные репозитории (remotes), механизмы слияния (merging), файлы исключений (ignore rules) и полноценный дифференциальный анализ (diff). Несмотря на это, реализация подобной системы за менее чем час работы с помощью локальной LLM демонстрирует значительный прогресс в способности моделей генерировать сложные программные концепции на основе публичных знаний без прямого доступа к оригинальным исходным кодам.
В ходе работы над проектом автор подчеркнул, что его целью не была попытка превзойти Линуса Торвальдса или создать инструмент, способный заменить оригинальный Git. Автор не стремился превратить tinyvcs в коммерческий продукт или проект, достойный подписки за 4,99 доллара. Основная задача заключалась в том, чтобы понять, насколько далеко локальная модель может продвинуться в создании системы контроля версий с нуля, опираясь исключительно на публичные знания и собственный код, без возможности использовать справочники или онлайн-документацию в реальном времени. В сравнении с оригинальной историей создания Git, на которую у Линуса ушло 10 дней, модель справилась с архитектурным каркасом за несколько часов, что автор считает отличным результатом для концепта.
Особое внимание в процессе «дрессировки» нейросети было уделено платформе Open WebUI. Автор выбрал её из-за распространенности среди энтузиастов, занимающихся селф-хостингом моделей, и удобства работы с интегрированным инструментом Open Terminal. Именно наличие доступа к терминалу внутри веб-интерфейса позволило модели Qwen не просто генерировать код, но и проверять его работоспособность в изолированной среде, выполняя те самые 36 утверждений для 14 тестовых кейсов.
Важным аспектом, который был упущен в начальных итерациях, стала дисциплина ведения документации. Изначально модель воспринимала DEVLOG.md как план проектирования или список тестов. Автор применил серию корректирующих промптов, чтобы заставить ИИ вести полноценный журнал разработки, отражающий реальный процесс внесения правок, обнаружение ошибок и их последующее устранение. Это было необходимо для того, чтобы tinyvcs не просто функционировала «здесь и сейчас», а обладала прозрачной историей разработки, имитирующей работу живого программиста.
В завершение эксперимента автор отметил ироничный момент: он потратил значительное время, пытаясь «сломать» написанный моделью скрипт, намеренно совершая ошибки в именовании файлов или провоцируя конфликты при слиянии состояний. Однако tinyvcs.py на удивление успешно справлялась с большинством проверок, демонстрируя устойчивость, характерную для стабильных релизных версий программного обеспечения. Это подтверждает, что при правильном подходе локальные LLM уровня 27B способны стать полноценными ассистентами, способными проектировать сложные архитектурные сущности, даже если они пока не покрывают весь спектр возможностей современных VCS.
