Десять репозиториев, десять архитектур Откройте любые три репозитория в вашей компании. Один использует уровень обслуживания, другой помещает SQL в обработчики маршрутов, третий имеет папку utils/, которая делает все. Кнопки трех оттенков синего цвета. Каждое репо имеет свое о...
Десять репозиториев, десять архитектур
Откройте любые три репозитория в вашей компании. Один использует уровень обслуживания, другой помещает SQL в обработчики маршрутов, третий имеет папку utils/, которая делает все. Кнопки трех оттенков синего цвета. В каждом репозитории есть собственный файл CLAUDE.md или AGENTS.md, скопированный из другого репозитория шесть месяцев назад и с тех пор отредактированный.
Потом кто-то решает: «Отныне каждый API возвращает ошибки в этом формате». Это решение принимается на собрании, затем на вики-странице, а затем, возможно, в двух из десяти файлов CLAUDE.md. Помощники по кодированию в остальных восьми репозиториях никогда об этом не слышали.
А документы? Они были правы в день отправки. Никто не обновляет страницу после очередного рефакторинга, потому что никто не помнит о ее существовании.
Помощники по кодированию сделали ситуацию одновременно хуже и лучше. Хуже того, потому что они пишут код быстро, в каком бы стиле ни предлагал местный контекст. Лучше, потому что они очень хорошо следуют инструкциям, если каждый из них получает одни и те же инструкции.
Идея: решить один раз, в одном репозитории
Я создал Ohara, инструмент с открытым исходным кодом, который помещает все рекомендации и все документы в один репозиторий GitHub. Помощники по программированию читают его вживую через MCP. Люди читают это на сайте. Ничего не копируется в каждый проект.
