
Як працюють coding agents: контекст, sandboxes, тести та відновлення
14.10.2026
Continual Improvement для AI-агентів: як перетворювати збої на перевірені можливості
14.10.2026Коли я ставлю ШІ-асистенту питання про проєкт, я не хочу, щоб він починав із порожньої розмови. Мені потрібно, щоб він знайшов уже відоме, перевірив авторитетну версію, зрозумів поточну мету й залишив результат, який можна перевірити та використати знову.
Для цього я й будую свою AI OS. Це організоване робоче середовище для знань, аналітичних процесів, спеціалізованих просторів і контрольованого виконання. Воно не замінює Windows чи Linux, не зводиться до одного чатбота й не означає, що програма самостійно керує всіма моїми проєктами.
Практична мета — результат бізнесу: кращі рішення щодо продажів, кваліфікованих лідів, витрат і обмеженого часу людей. Дашборд — один із результатів. Важливішими є докази та процес, що стоять за ним.
Постійні знання замість пам’яті окремої розмови
Корисна розмова може містити важливе рішення, посилання, виправлення й невдалий експеримент. Якщо вони залишаться лише в історії чату, наступна задача може повторити дослідження або спиратися на застарілу відповідь.
Моє єдине джерело істини — SSOT — зберігає довготривалі знання проєктів поза розмовою з будь-якою окремою моделлю. Це погоджені рішення, реєстри джерел, збережені докази, багаторазово застосовувані методи, робочі документи та записи виконання. Історичні версії залишаються доступними; поточний покажчик визначає версію для наступного рішення.
Це не робить усі файли однаково достовірними. Чернетка пропозиції, погоджене власником рішення, спостереження з джерела й перевірене впровадження мають різний статус і вагу для ухвалення рішень. Система має зберігати ці відмінності й не вважати істинним файл із найсвіжішою на вигляд назвою.
Тому перший крок — знайти й узгодити наявні знання. Збирати або перераховувати потрібно лише відсутню, застарілу чи критичну для рішення частину. Конфлікт доказів зберігається разом із поясненням, яке джерело визначає конкретне твердження.

Зберігати історію з доступною деталізацією
Щоденні маркетингові спостереження дають змогу порівнювати дні, тижні та відповідні періоди різних років. Подієві записи можуть підтримувати відновлення шляху клієнта. Місячні вимірювання залишаються місячними. Місячний підсумок не доводить, що відбувалося кожного окремого дня.
Корисне покриття визначається найранішими й найпізнішими перевіреними спостереженнями, охопленими інтервалами, прогалинами та визначеннями показників. Я не прирівнюю обсяг сховища до повноти аналізу. Експорти, що перекриваються, і повторні запити не створюють додаткових клієнтів або історії.
Ланцюг доказів відокремлює оригінальні знімки від нормалізації, узгоджених бізнесових сутностей, прийнятих аналітичних представлень та кінцевих матеріалів. Графік має простежуватися назад цим ланцюгом. Якщо оновлення не пройшло перевірку, попередній прийнятий шар залишається доступним із реальною датою його спостережень.
Визначити відповідальність робочих просторів
Один простір може підтримувати збір джерел. Інший відповідає за визначення показників. Спеціаліст готує статтю, переклад, ілюстрацію чи технічну зміну. Рецензент перевіряє відповідний результат. Координатор зберігає пріоритети, залежності й рішення, а не кожну проміжну деталь.
Передача роботи потребує більше, ніж слова «продовжуй». Вона містить мету, входи та їхні версії, погоджені межі, дозволені зміни, невирішені питання, перевірки приймання та адресу повернення результату. Відправлення такого пакета — факт доставки, а не доказ завершення задачі адресатом.
Так само працює сайт. Редакційна підготовка, штатне впровадження в CMS та незалежна перевірка змінених сторінок — різні обов’язки. Підготовлена стаття не дорівнює опублікованій. Успішна зміна на стейджингу не дорівнює релізу на продакшені.
Давати агентам обмежені задачі
Агенти можуть знаходити докази, нормалізувати записи, перевіряти структуру, обчислювати порівняння або готувати пояснення. Їхня користь залежить від визначеної задачі й результату, який можна перевірити, а не від кількості залучених агентів.
Для невеликого питання може вистачити одного компетентного асистента. Додаткові ролі корисні, коли забезпечують справді іншу перевірку або відповідають за окрему частину роботи. Вони мають використовувати посилання на прийняті докази, а не створювати різні копії бізнесових правил.
Постачальники моделей — виконавці, а не власники бази знань. Це архітектурний напрям. Він не означає, що кожен адаптер, процедура відновлення чи режим одночасної роботи кількох машин уже пройшли експлуатаційне приймання.
Відокремлювати висновок від права діяти
Агент може виявити погіршення якості лідів каналу. Це не дає йому права змінювати рекламний бюджет. Аналіз лише для читання, підготовка кандидата, погодження та виконання — окремі етапи.
Я визначаю бізнесову мету й відповідаю за прийняття суттєвих рішень. Відповідні люди зберігають свої обов’язки. Доступ до джерел, публікація та бізнесові зміни із суттєвими наслідками мають власні дозволи; внутрішня передача задачі їх не розширює.
Спільні записи також потребують відповідального виконавця запису. Кілька читачів можуть перевіряти докази чи готувати ізольовані кандидати. Вони не повинні одночасно перезаписувати той самий авторитетний файл або об’єкт CMS. Перед публікацією виконавець перевіряє, чи не змінилася вихідна версія.

Робити невизначеність частиною результату
Корисна відповідь розмежовує перевірене спостереження, розрахунок, гіпотезу й невідоме. Впевненіше формулювання не компенсує відсутнього джерела.
Атрибуція — практичний приклад. Відстежений шлях може підтверджувати документований зв’язок залучення, але не автоматично додатковий продаж. Дашборд може бути доступним онлайн, хоча окремі джерела можуть запізнюватися, бути попередніми або оновлюватися вручну. Ці межі мають бути поруч із рішенням, на яке впливають.
Записи невдач — теж багаторазово застосовувані знання. Виправлення зберігає, що пішло не так, як це виявили, що змінили й яка наступна перевірка запобігає повторенню. Мета — не бездоганна на вигляд історія, а менше повторної роботи й помилок.
Чесно описувати стан впровадження
Частини цього підходу вже використовуються в повсякденній роботі: довготривалі записи, правила проєктів, посилання на джерела, обмежені передачі задач і докази перевірки. Деякі інтеграції та аналітичні представлення працюють і вдосконалюються. Інші можливості залишаються спроєктованими, локально протестованими, умовними або заблокованими.
Ці стани не взаємозамінні. Успішний тест на умовних даних не доводить готовності продакшену. Підключене джерело не доводить повної історії. Розміщене онлайн представлення не доводить збору без участі людини. Політика управління сама не розгортає середовище виконання.

Що система має залишати після роботи
Після корисної задачі має залишатися більше, ніж відповідь: зрозумілий висновок, докази та їхній період, відтворюваний розрахунок за потреби, визначені обмеження, наступна безпечна дія й збережений результат.
Приклад — робота із сайтом: прийнятий двомовний пакет передається окремому виконавцю CMS, а потім перевіряються змінені сторінки, перш ніж повідомляються їхні адреси. Інший приклад — News Radar: знайдений заголовок створює кандидата для перевірки джерел, а не автоматичну публікацію.
Для пояснення не потрібно відкривати приватні простори, клієнтів чи облікові доступи. Публічна схема показує логіку, тоді як операційні доступи й конфіденційні докази залишаються приватними.
Для мене AI OS — спосіб накопичувати знання й робити роботу перевірюваною. Критерій — чи допомагає вона реальному рішенню, зберігає докази й дотримується межі між розумінням ситуації та її зміною.



