I was “just” a CMS developer.
Then came AI

Я розробник, і я робив CMS.

Я працював із ними значну частину останніх двадцяти років. CMS часто означала WordPress, а WordPress означав сайти. Це зрозуміла асоціація, але вона розповідає лише про частину роботи.

Заголовок, фотографія та кнопка «Опублікувати» можуть бути всім, що видно. За ними можуть стояти редакції, переклади, права доступу, інтеграції та роки контенту, який має пережити наступне оновлення. Саме працюючи над цими проблемами, я навчився найбільше.

Сьогодні ШІ дозволяє значно більшій кількості людей створити застосунок, систему керування бізнесом чи навіть власну CMS. Мене це захоплює. І в цих проєктах я впізнаю багато проблем, над якими ми працювали роками.

Що легше генерувати програмне забезпечення, то корисніше знати, що воно має вміти протягом тривалого часу. Саме про цей досвід я хочу поговорити.

Програмне забезпечення починається з людей, які ним користуються

Людина, яка відкриває CMS, зазвичай хоче завершити роботу: опублікувати статтю, оновити каталог, організувати подію. Наша модель даних має відповідати цій роботі. Обов’язкове поле може бути цілком логічним у базі й водночас неможливим для заповнення на етапі начерку. Рано чи пізно хтось напише «визначити пізніше», і обмеження погіршить дані.

Це продуктовий урок, який одразу стає архітектурою: відрізняти чернетку від готового до публікації матеріалу, запитувати інформацію вчасно, робити помилку зрозумілою, а відновлення можливим.

У корпоративному ПЗ покупець і користувач часто різні люди. Працівник може роками жити з незручним інтерфейсом. У споживчих продуктах, які легше покинути, та сама незручність може коштувати клієнта. Багато CMS десь посередині: робочі інструменти для людей із різними навичками, звичками та терпінням. Добра школа поєднання структури й зручності.

У сучасних застосунках видно знайомий підхід. CRM, система керування нерухомістю, адміністративна панель: фільтрую інформацію, вибираю подання, щось роблю. Запит, подання, дія. Таблиця, календар і канбан можуть бути трьома способами роботи з тими самими даними.

Ця граматика має коріння також у базах даних і бізнес-системах. CMS давно застосовували її для людей, яким треба було працювати щодня, не знаючи зовнішніх ключів. Тепер ШІ дозволяє створити подання для одного завдання, можливо, лише на десять хвилин. Під ним значення даних і правила їх зміни мають залишатися впізнаваними.

Анатомія CMS

Візьмімо Directus, бо я з ним працюю й можу розглянути зблизька. «База даних з API та панеллю» приблизно так само точно, як описати тварину як щось зі шкірою й органами. Щоб зрозуміти, що ми купуємо, повторно використовуємо чи хочемо відтворити з ШІ, треба розділити його відповідальності.

Почну ззовні. Шкіра: це Data Studio: форми, подання й панелі роблять систему придатною до використання. Але приховування поля у формі не захищає його на сервері. Скелет: це модель даних: таблиці та зв’язки SQL разом із метаданими, якими Directus описує поля, інтерфейси й налаштування. Що означають «клієнт», «проєкт» і «схвалено», визначаємо ми. Потім відкриваємо кролика.

Вирішальна відмінність між тим, що вміє Directus, і рішеннями, які маємо ухвалити ми. Він пропонує колекції, зв’язки, права, версії та автоматизацію. Визначення того, хто схвалює витрату, коли чернетка готова до публікації та як упізнати того самого клієнта у двох системах, потребує моделі нашої роботи. Продукт дає засоби її виразити; за правильність моделі відповідаємо ми.

Простежмо конкретну зміну: редактор змінює ціну товару. Data Studio збирає значення; API отримує запит; сервіси виконують його в контексті користувача та налаштованих прав. База застосовує власні обмеження. Історія зберігає зміну, якщо її налаштовано. Flow може запустити оновлення зовнішнього каталогу. Це різні відповідальності: якщо останній сервіс не відповідає, збережена ціна й показана деінде можуть розійтися. Потрібні правило відновлення й спосіб це помітити.

Межі важливі й під час розширення платформи. Документація сервісів закликає уважно ставитися до контексту авторизації, який називається accountability: його пропуск може надати сервісу адміністративні права.³ А приховане поле в Data Studio не замінює політику доступу до даних.⁴ Цінність платформи залежить і від дотримання її меж.

Поза твариною залишаються експлуатація й підтримка: база та сховище, секрети, перевірені резервні копії, моніторинг, оновлення й сумісність клієнтів. Частину можна передати керованому сервісу, але треба знати, хто за неї відповідає. Міграція схеми чи відновлення ревізії розв’язує частину проблеми, а не замінює повний план відновлення.

Вибір ліцензії теж нагадує про вартість цілого. Directus зараз застосовує MSCL, ліцензію source-available: вихідний код можна переглядати, використання залежить від чинних умов.⁵ Оцінюючи альтернативу, треба враховувати довгострокову вартість відповідальностей, які вирішуємо взяти на себе.

Зручність також за межами браузера

Така сама увага потрібна людям, які працюють через код, скрипти й автоматизацію. Developer experience, або DevEx, є іншою формою зручності: ясна документація, явні типи, передбачувані команди, зрозумілі помилки. Це дозволяє діяти точно й повторювати операції з відомими очікуваннями.

У Directus ця увага має конкретні форми. SDK для JavaScript і TypeScript дає компонований клієнт API, автентифікації та роботи в реальному часі з підтримкою типів власної схеми.⁶ CLI синхронізації середовищ дозволяє експортувати схему й налаштування, переглядати відмінності та застосовувати їх до сумісних екземплярів, зокрема в конвеєрі.⁷ Сервер MCP через Model Context Protocol відкриває дані й операції асистентам ШІ, дотримуючись прав ідентичності, з якою вони під’єдналися.⁸

Це дає реальну свободу: користуватися панеллю, написати інтеграцію, виконати команду чи працювати зі своїм агентом у своєму середовищі. Можна вибрати спосіб взаємодії й отримати ту саму модель даних із правами, потрібними для кожної операції. ШІ входить у систему, яка вже має структуру й правила.

Для мене «гарне й зручне» включає ПЗ, яке людина може оркеструвати, зокрема через свого агента. Я можу скласти процес, делегувати кроки, перевірити результат і втрутитися. Автоматизація стає способом краще контролювати роботу. Продумана DevEx робить це доступним уже сьогодні.

«Це лише галерея зображень»

Звичайне прохання: головне зображення статті має стати впорядкованою галереєю. Додаємо до форми мініатюри та перетягування. Начебто спокійний день.

Але модель переходить від одного посилання до зв’язку з кількома зображеннями та порядком. Наявні статті мають зберегти фотографії. API й шаблони повинні розуміти нову структуру. Права мають дозволити редакторам керувати також зв’язком, не відкриваючи небажаного доступу до файлів. А редактори тим часом продовжують працювати.

Можна рухатися поетапно: додати зв’язок, перетворити наявні посилання на перше зображення кожної галереї, оновити читання, прибрати старе поле. Під час переходу треба визначити й обробку нових записів: якщо хтось змінить старе фото після першої міграції, зміна має потрапити до галереї. Сумісне розгортання враховує також те, що відбувається під час його виконання.

Схема, дані, файли й код мають працювати разом на кожному етапі зміни. Вони можуть розвиватися в різний час, якщо передбачено шлях, що зберігає сумісність.

Тому перенесення схеми з розробки у виробниче середовище й перенесення контенту є різними операціями.⁹ Тому повернення до вчорашнього коду може залишити зламану систему, якщо дані вже перетворено. І тому самої резервної копії бази може не вистачити: якщо вона посилається на видалені зображення, ми відновили посилання на те, чого більше немає.

Від галереї ми дійшли до аварійного відновлення. Треба знати, які файли зберігати, які версії коду відкриють дані та як перезапустити інтеграції без повторення виконаних дій. Надісланий лист або операція в зовнішньому сервісі не відкочуються разом із базою.

Тут вступає майстерня навколо CMS: інфраструктура, конвеєри CI/CD, спостережуваність, перевірки відновлення. Вона дозволяє випускати зміни в точному порядку, відрізняти хибні права від недоступного сервісу й перевіряти, скільки роботи можна втратити через інцидент. Є й люди: хто схвалює зміну, хто втручається, хто знає, навіщо існує дивне правило.

У welance наша хмара та процеси навколо неї є частиною цього спільного досвіду. Люди, які супроводжували складні CMS, часто приносять цілий спосіб роботи, набагато менш помітний, ніж екран.

ШІ може допомагати писати міграції, тести й процедури відновлення. Досвід допомагає зрозуміти, які саме потрібні й чи справді перевірки доводять важливе для нас. Прототип показує, що щось може працювати; подальша робота визначає умови, за яких воно працюватиме й надалі.

C означає content, тобто контент

Досі я говорив про статті й фотографії. Але контентом можуть бути вимога, нерухомість, доступність, рішення чи зв’язок проєкту з людиною. Ця відкритість завжди приваблювала мене в CMS.

Достатньо гнучка система може стати основою керування нерухомістю, CRM або частин ERP. Вона вже дає місце для опису сутностей, їх поєднання, призначення доступу й створення інтерфейсів. Додаються знання предметної області: бронювання має запобігати накладанням навіть за двох одночасних запитів; бухгалтерське рішення має обмеження, яких стаття не має.

CMS цікавить мене саме як простір для цих можливостей. Значна частина бізнес-систем структурує інформацію й дозволяє належним людям діяти з нею. З ШІ додається учасник, здатний читати, пропонувати й виконувати дії. Якість структури стає ще важливішою.

Коли пам’ять стає операційною

Спільна пам’ять стає операційною, коли можна простежити дані до їхнього джерела, рішення до його причин, а дію до правил, що її дозволяють.

Знання стає раціональним тією мірою, якою ми можемо його відтворити й перевірити. Зареєстрована операція, оцінка й висновок моделі мають залишатися відмінними. Правила розрахунку та зв’язки повинні бути доступними для перевірки. Це дозволяє різним людям із різними агентами працювати з тими самими фактами й обговорювати тлумачення.

Тут бачу зв’язок із LLM Wiki, запропонованою Андреєм Карпаті: модель читає джерела й підтримує тривале знання через узагальнення та посилання, які змінюються з часом.¹¹ У CMS можна прив’язати його до проєктів, відповідальностей і станів: яку вимогу схвалено, хто може її змінити, яке завдання від неї залежить.

Джерелами можуть бути документ, запис або фотографія. Інструменти, що їх тлумачать, мають зберігати походження, щоб людина могла перевірити й виправити узагальнення. Модель може змінитися; дані, рішення й зв’язки повинні мати змогу залишитися. У цьому сенсі система стає частиною інтелекту компанії.

Перехід до дії вимагає точних дозволів. Читання вимоги не дає автоматично права змінити проєкт або щось надіслати клієнту. Кожен конектор має перевірити запитану дію й використати належні облікові дані зовнішнього сервісу. MCP дає спільний спосіб поєднання інструментів; відповідність прав різних систем треба спроєктувати. Навіть узагальнення конфіденційних документів має поважати ці межі.¹²

Саме цю еволюцію я уявляю під назвою AI Management System, або AI MS: бізнес-система, де люди й агенти працюють зі спільною операційною пам’яттю. Кожен взаємодіє по-своєму, а правила, відповідальності й історія змін залишаються перевірними. Це робоча назва напряму, який здається перспективним.

Можливо, прибрати варто саме CMS

Найсильніше заперечення моєї тези: ШІ може зробити дані й правила важливішими, а CMS, що їх об’єднує, менш потрібною. Відповідальності анатомічної таблиці можна скомпонувати інакше. Описані навички належать програмній інженерії. Те, що я опанував їх через CMS, не доводить, що CMS досі найкращий вибір.

Якщо спеціалізовані інструменти дешевше будувати, змінюється вигода пристосування до універсальної платформи. Невеликий застосунок навколо власної роботи може бути кращим за CMS, повну розширень. SDK, CLI й MCP підтримують і цю альтернативу: роблять продукти доступними та компонованими, не обов’язково надаючи їм центральну роль.

Спільна модель теж має ціну. Проєкт для планувальника й замовлення для того, хто виставляє рахунок, можуть мати різні межі. Domain-driven design працює саме з цією множинністю: окреслює моделі та робить їхні зв’язки явними.¹³ Звести їх силоміць до однієї структури означає ризикувати крихкими перетвореннями, застарілими копіями й точкою, через яку проходить кожна зміна.

Розумна альтернатива залишає авторитетні системи у власних сферах і поєднує їх явними контрактами. Агент координує операції; сервіси далі застосовують свої правила. CMS може залишитися там, де потрібна редакторам, або повністю вийти з цього процесу. Я маю враховувати це, зокрема щоб не бачити в майбутньому передусім найзнайоміший інструмент.

Для мене CMS заслуговує на місце, коли спільні зв’язки, права та редакційні процеси становлять значну частину роботи. Якщо треба дублювати вже надійні деінде правила й постійно синхронізувати дані, перевага може зникнути. Практична перевірка: уявити її відсутність: які відповідальності доведеться відбудувати, які інтеграції зникнуть і наскільки складніше буде зрозуміти чи виправити помилку? Найкращий вибір зменшує загальну роботу, зберігаючи потрібні гарантії.

Інструменти, якими я хотів би користуватися завтра

Цей погляд визначає інструменти, які мене цікавлять. Подобається підхід Railway: сервіси й середовища є видимими частинами проєкту. Lovable починає зі створення застосунку й також пропонує керований бекенд із базою, автентифікацією та сховищем.¹⁴ Це різні способи зробити систему доступною, хоча під нею залишаються залежності.

Віддаю перевагу платформам, які роблять залежності зрозумілими й допомагають ними керувати. Створення через розмову уявляю як одну з можливостей ширшої платформи, що супроводжує ПЗ після першого випуску.

Хочу попросити «перетвори це зображення на галерею» й побачити, які дані зміняться, як оброблять наявні, які сервіси долучаться й де потрібне схвалення. Також хочу знати шлях відновлення, якщо щось піде не так. Намалювати компоненти на полотні: добрий початок; цінність у керуванні зміною, яка проходить крізь них.

Звідси може постати наступна CMS, або вона виросте з наявних інструментів. Мені важливо, щоб людина могла вибрати інтерфейс і агента, продовжуючи роботу на спільній основі. Вирішальною буде здатність супроводжувати зміну від наміру замовника до наслідків для системи.

Хай живе CMS

У світі CMS теж чимало роботи роблять за інерцією: встановлюють тему, накопичують плагіни й здають проєкт, не замислюючись, як система працюватиме далі. Сам досвід роботи з CMS не свідчить про старанність чи компетентність. Легкий початок може заохочувати і допитливість, і лінощі.

Дивлячись на те, що ми сьогодні створюємо із ШІ, я насамперед помічаю те, що завжди було очевидним: хороше програмне забезпечення залишається хорошим програмним забезпеченням. Його впізнаєш за тим, як воно допомагає користувачам і як витримує плин часу та зміни. Назви, абревіатури й модна нині технологія самі по собі мало про що говорять.

Тим, хто сьогодні створює власну бізнес-систему з ШІ, залишив би чотири запитання, які й далі ставив би собі:

• Які правила мають залишатися істинними, поки система змінюється?
• Хто може діяти, з якими даними та з якими наслідками?
• Що ми справді пробували відновити після помилки?
• Що знатимуть ті, хто прийде після нас?

Саме працюючи з CMS, я навчився ставити ці запитання. Беру набуті знання із собою, зокрема й тоді, коли вони допомагають вибрати іншу архітектуру.

CMS is dead. Long live the CMS.