Ваша команда шипить код чотирма різними AI-інструментами. Може, п'ятьма. Бекендер клянеться Claude Code, фронтенд живе в Cursor, джун відкрив GitHub Copilot на першому курсі й більше не випускав, а хтось в інфраструктурі тихенько поставив собі JetBrains AI. Всі продуктивні. Код компілюється. CI проходить. Ніхто не ставить це під сумнів.

Але є нюанс: ваша кодова база тепер читається як роман, написаний чотирма гострайтерами, які ніколи не зустрічалися. Кожне речення граматично правильне. Книга загалом — повна маячня.

Розкол вже офіційний

10 квітня 2026 року JetBrains опублікував своє дослідження AI Pulse — 10 000+ професійних розробників, вісім мов програмування, статистична вибірка зі зважуванням. Головна цифра: Copilot — 29%, Claude Code і Cursor нарівні по 18%, JetBrains AI — 11%. Дев'яносто відсотків розробників використовують хоча б один AI-інструмент на роботі.

Це не перемога одного інструмента. Це перемога кожного інструмента всередині однієї організації.

І ось де починається цікаве: кожен інструмент притягнув свій файл інструкцій — конфіг, який пояснює AI, як писати код для конкретного проєкту. Claude Code читає CLAUDE.md. Copilot читає copilot-instructions.md. Cursor читає .cursor/rules/*.mdc. OpenAI Codex CLI читає AGENTS.md (тепер під крилом Linux Foundation, прийнятий 60 000+ open-source проєктами). Windsurf читає .windsurf/rules/*.md. Gemini CLI читає GEMINI.md.

Шість інструментів. Шість форматів конфігів. Кожен мовчки ігнорує інших. Як зазначив TokenCentric у порівнянні за березень 2026: «Розробник, який працює над п'ятьма проєктами з трьома AI-інструментами, може підтримувати п'ятнадцять конфіг-файлів.»

Як чотири AI пишуть чотири різні кодові бази

У кожного AI свій характер. Claude Code полюбляє явну обробку помилок і функціональну композицію — маленькі функції, чіткі типи, багатослівно, але передбачувано. Copilot дзеркалить статистичне середнє GitHub — він пише код так, як виглядає більшість open-source, тобто середньо в усіх сенсах. Cursor автоматично перемикається між моделями (Claude, GPT, свої файнтюни), змішуючи стилі всередині одного pull request залежно від того, яка модель обробляла який файл.

Ніщо з цього не є неправильним. Саме в цьому проблема. Лінтер — інструмент, що перевіряє код на стильові порушення — ловить друкарські помилки й форматування. Він не ловить того, що ваш сервіс авторизації обробляє помилки через try-catch, платіжний сервіс використовує Result types, а сервіс нотифікацій повертає null. Три підходи, всі валідні, всі проходять CI (Continuous Integration — автоматичні тести, що запускаються перед мерджем коду), й усі разом створюють кодову базу, по якій не можна орієнтуватися без карти.

Найсвіжіше масштабне дослідження якості AI-коду — звіт CodeRabbit за грудень 2025, все ще найкращі наявні дані чотири місяці потому — оцифрувало збитки на 470 GitHub pull requests: AI-код мав у 1,7 рази більше проблем загалом, утричі більше проблем з читабельністю і в 2,66 рази більше неконсистентностей форматування порівняно з людським кодом. І це вимірювали результат одного інструмента. Мульти-тулові кодові бази нашаровують ці неконсистентності одна на одну.

Прозріння, якого ніхто не хотів

Результат — не баги. Баги можна знайти. Результат — архітектурна некогерентність — термін, навколо якого Мартін Фаулер кружляв 7 квітня 2026 у своєму есеї про "harness engineering", де він сформулював рівняння: Agent = Model + Harness. Harness — це все, що оточує AI-модель: конфіг-файли, guardrails, інструкції. Фаулер визнав: «Нам ще багато роботи, щоб зрозуміти, як правильно будувати harness для функціональної поведінки.»

Переклад: ніхто ще не вирішив цю проблему.

Грег Фостер, CTO Graphite, висловився інакше у пості на Stack Overflow від 26 березня: людські інженери «неявно вбирають контекст кодової бази» під час роботи. Вони помічають, що решта сервісу використовує Result types — і теж використовують Result types. AI-агенти нічого не вбирають — вони слідують тому, що написано в конфіг-файлі, або, що гірше, тому, що підказують навчальні дані.

Цінник

Жоден існуючий інструмент цього не ловить. ESLint перевіряє синтаксис. Prettier перевіряє форматування. Код-рев'ю ловить баги. Ніхто не фіксує «цей файл очевидно написаний іншим AI, ніж файл поруч».

І не чекайте, що вендори добровільно наведуть мости. Якби Cursor зробив свої правила сумісними з конфігом Claude Code, це полегшило б перехід між інструментами. Фрагментація — це мoат, навіть якщо випадковий.

Ком'юніті-проєкти намагаються компенсувати. rule-porter, що з'явився на GitHub у лютому 2026, конвертує між форматами конфігів; rulesync, що з'явився приблизно тоді ж, намагається їх об'єднати. Обидва звітують приблизно про 75% чистої конвертації. Решта 25% — це те, де живе архітектурний намір, і він губиться при перекладі.

Addy Osmani з Google попередив у лютому 2026: «Чим чистіша ваша архітектура, тим менше AI галюцинує дивні абстракції.» Зворотне теж правда: чим брудніша ваша мульти-AI кодова база, тим дивнішим стає кожен наступний AI-внесок. Ентропія має властивість накопичуватися.

Що з цим робити

Якщо ваша команда використовує кілька AI-інструментів — а статистично так і є — вам потрібна одна річ: єдиний, тул-агностичний документ стилю, який читають всі AI. Не шість конфіг-файлів. Одне канонічне джерело правди про те, як ваша кодова база обробляє помилки, структурує API, називає сутності й організовує залежності. А потім pre-commit hook — автоматична перевірка, що запускається перед збереженням коду — який енфорсить ці патерни незалежно від того, який AI написав код.

Стандарт AGENTS.md, тепер під крилом Linux Foundation, — найближче до універсального формату. Він не ідеальний, але це єдиний формат із крос-вендорною підтримкою.

Нова нормальність

У вашій кодовій базі тепер більше AI-авторів, ніж людських. Andrej Karpathy сказав це прямо ще 26 січня 2026: «Ви не пишете код напряму 99% часу… ви оркеструєте агентів.» Добре. Але оркестрам потрібен диригент, і їм потрібна партитура. Зараз більшість команд мають чотирьох музикантів, які грають з чотирьох різних нот у чотирьох різних тональностях — а аудиторія чує «компілюється» і вважає, що це музика.

Хтось має написати редакційну політику, поки репозиторій не написав її за вас. Гарно не буде.