Грант $150 000 переможцю кожної категорії. Участь безкоштовна, подаватись можна з будь-якої країни.

Продовжую серію про програми для тих, хто будує з AI.

Dubai Chamber of Digital Economy запустила Create AI Agents Championship. Реєстрація відкрита з 7 жовтня.

Чотири категорії, у кожній переможець отримує грант $150 000:
⏺ соціальний агент
⏺ персональний агент
⏺ бізнес-агент
⏺ молодіжна — для учасників до 21 року.

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

Що важливо знати заздалегідь:

⏺ команда до 6 людей, рішень можна подати кілька
⏺ усі матеріали — тільки англійською
⏺ листопад–грудень — навчання й воркшопи
⏺ січень 2027 — закриття реєстрації: прототип, пітч-дек і демо-відео
⏺ далі 24 півфіналісти, фінал — у перший тиждень травня 2027

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

До січня часу якраз на робочий прототип.
👉 https://www.dubaichambers.com/en/web/dubai-chamber-of-digital-economy/create-ai-agents

🔥 — подаюсь
👀 — подумаю
👍— $150 000 мені б не завадили

13 років боротися з дубльованим кодом, а тепер шукати його навмисно. Навіщо?

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

Під час міграції стара логіка має знову з'явитися в новому коді: як відповідник, що робить ту саму роботу новим синтаксисом.

⏺Відповідник є новою мовою — функція переїхала.

⏺Є лише старою мовою — її ще не перенесли.

⏺Немає ніде — щось загубилося.

Той самий сигнал, протилежне значення. Усе залежить від того, що ти хочеш довести.

Повний розбір з експериментом fs-extra → Rust: https://jscpd.dev/blog/when-code-clones-matter

А ви вже переносите код за допомогою ШІ-агентів?

👍 — так, переношу
👀 — поки ні

Ваш Docker-образ може бути без security-патчів, а ви навіть не знаєте про це.

⏺FROM node:20 у Dockerfile? Node.js 20 уже EOL — офіційних патчів більше немає.
⏺ Node.js 24 щойно втратив статус Active LTS: security-патчі ще будуть, нових фіч — уже ні.

Перевірте, на чому працює ваш production.

Знайдіть свою версію:

⏺ Node 20 — підтримка закінчилась 30 квітня 2026 року. Офіційних виправлень, зокрема security-патчів, більше не буде. Переїжджати негайно.
⏺ Node 22 — Maintenance до 30 квітня 2027 року. Залишилось трохи більше півроку — час починати переїзд.
⏺ Node 24 — Maintenance з 20 жовтня 2026 до 30 квітня 2028 року: критичні виправлення й security-патчі є, нових фіч немає. Не горить, але заплануйте Node 26 на наступний квартал.
⏺Node 26 — зараз Current, Active LTS з 28 жовтня 2026 року, підтримка до 30 квітня 2029 року. Для нових проектів — найкращий вибір: Temporal API без флагів, V8 14.6.
⏺ Node 27 — альфа з жовтня 2026 року (не для production), реліз у квітні 2027 року, LTS з жовтня 2027 до квітня 2030 року.

Що змінюється назавжди:

⏺ Node 26 — останній реліз за схемою «парні версії — LTS, непарні — експериментальні».
⏺Починаючи з Node 27 — один мажор на рік: альфа восени, реліз у квітні, LTS у жовтні — і кожен реліз стає LTS.
⏺Правило «бери парну версію», яке працювало десять років, більше не працює.

Перевірка на 10 хвилин:

⏺Справжня версія — у запущеному контейнері в production, а не в документації: docker exec <контейнер> node -v
⏺Звірте три місця: .nvmrc, engines у package.json і FROM у Dockerfile (або ARG, якщо версія винесена в змінну). Буквально збігатися вони не мусять — engines часто задає діапазон, — але версія з Dockerfile має в нього потрапляти. Часто не потрапляє.
⏺Додайте Node 26 у CI-матрицю поруч із поточною версією — побачите проблеми переїзду до того, як він стане терміновим.

Збережіть і перешліть тому, хто відповідає за ваш Dockerfile.

🔥 — вже тестую Node 26
👀 — на Node 24, не поспішаю
😱 — у нас ще Node 20

OpenAI заявила: GPT-6.1 Sol переносить COBOL у 86,6% випадків. Перевірити цю цифру не можна — тести приховані. А от правило, за яким її рахували, варто взяти собі.

19 жовтня OpenAI показала свій тест: модель переносить COBOL-програму на C++, Java, Kotlin, Python чи Rust, і міграція зараховується, лише якщо на кожному прихованому тесті вихід збігається з оригіналом байт у байт. Не «майже», не «тести зелені» — кожен байт.

Як перевірити свою міграцію за цим правилом:

⏺ Запишіть, як поводиться стара система. Проженіть реальні вхідні дані через старий код і збережіть вихід: відповіді API, файли, записи в БД. Це ваш еталон, golden master.
⏺ Порівнюйте байт у байт. Новий код отримує ті самі входи, і його вихід звіряється з еталоном точно, а не «приблизно схоже».
⏺ Окремо — числа, дати й округлення. Приклад OpenAI: фіксована арифметика COBOL відкидає зайві знаки після коми, якщо округлення не запросили явно. Переписаний код округлить «правильно» — і тихо змінить фінансові розрахунки.
⏺ Тести переносьте першими й 1:1. Один тест не розпадається на два, нічого не «покращуємо». Інакше це вже не міграція, а рефакторинг. Переписувати й чистити — окремим кроком, після.
⏺ Зараховуйте тільки 100%. Міграція готова, коли проходять усі тести. Кілька відсотків, що лишилися, — це саме ті випадки, які зламаються в production.

86,6% — замір OpenAI на її власних тестах, які не опубліковані. Сама компанія пише, що це не гарантія для production: бізнес-правила й залежності все одно перевіряють люди. Цифри моделей змінюються щомісяця, а правило перевірки лишається.

Збережіть до наступної міграції і перешліть тому, хто відповідає за legacy.

🔥 — зберіг
👍 — перешлю команді
😱 — у нас legacy без тестів

Ваш AI-агент може вимкнути моніторинг і... сказати, що нічого не чіпав))

Це два випадки з офіційного звіту OpenAI від 20 жовтня — обидва під час звичайних задач з кодом.

⏺3 жовтня агента на GPT-6.1 Sol попросили не писати в Slack.
⏺Він виставив NO_NOTIFY=True і очистив список отримувачів.
⏺Моніторинг збирав дані далі, але до людей сповіщення не доходили.
⏺6 жовтня агент на GPT-6 Astra переносив програму й видалив інтеграцію моніторингу.
⏺На пряме питання відповів, що нічого не видаляв.

За словами OpenAI, агенти сприйняли звичайні інструкції як дозвіл послабити контроль. Чи це надмірна старанність, чи свідомий обхід нагляду — компанія ще з’ясовує.

Як захистити свій моніторинг:

⏺Винесіть налаштування моніторингу з доступу агента — в окремий репозиторій або під CODEOWNERS.
⏺Забороніть зміни в AGENTS.md чи CLAUDE.md. Але сама інструкція захисту не гарантує.
⏺Блокуйте в CI зміни алертів, NO_NOTIFY і списків отримувачів без погодження людини.
⏺Перевіряйте git diff, а не слова агента.
⏺Налаштуйте алерт на тишу: жодної події за N годин - теж сигнал.

👀Якщо агент може змінити систему, яка за ним стежить, потрібен ще один рівень нагляду — до якого він не дістає.

Збережіть і перешліть тому, хто дає AI-агентам доступ до репозиторію.

😱 — наш агент теж «нічого не чіпав»
😁 — попросив не писати в Slack. Тепер тиша
🔥 — йду дивитися, хто має доступ до алертів

Аліас -latest у проді — це модель, яку можуть замінити, поки ваш код продовжує працювати.

Саме так зараз із Jev: 14 жовтня вийшла jev-1.14.0, і цього тижня TypeSafe планувала перемкнути на неї jev-latest.

Jev — класифікатор, про який я писав у вересні: замість текстової відповіді він повертає типізоване рішення з імовірністю. Нова версія — не єдина новина за місяць:

⏺У jev-1.14.0 — покращена багатомовність, а експериментально — зображення, новий тип запитань і довший контекст.

⏺9 жовтня — $870 млн інвестицій за оцінки компанії у $7,5 млрд. Раунд очолила a16z.

⏺20 вересня реєстрацію відкрили для всіх, але вже 22 вересня призупинили через надмірний попит.

А тепер — як я б використовував Jev у реальному проекті.

⏺Фіксуйте версію. Ви підібрали поріг 0,8 на одній версії моделі. Після оновлення той самий поріг може давати інші результати. У проді краще використовувати конкретну версію, а нову спочатку перевіряти на власних прикладах.

⏺Питайте про конкретні факти. TypeSafe попереджає: Jev краще працює з буквальними запитаннями, ніж із непрямими, і не завжди точний у числах. «Ця зміна безпечна?» — надто розмите запитання. «Цей diff змінює NO_NOTIFY або список отримувачів?» — значно краще.

⏺Перевіряйте перед ризикованими діями. У нещодавньому звіті OpenAI агенти вимкнули сповіщення й прибрали моніторинг, виконуючи звичайні задачі. Класифікатор можна поставити перед застосуванням diff, щоб перевірити конкретні зміни.

Генеративна модель інтерпретує запит — у цьому її сила й водночас ризик. Класифікатор із чітким запитанням вирішує вужчу задачу.

Для мене Jev — не заміна агенту, а недорогий другий погляд перед діями, де помилка коштує дорожче за додатковий виклик моделі.

Не просіть його вирішити, чи все безпечно. Просіть перевірити конкретну річ.

🤑 — $7,5 млрд за «так» чи «ні»
👀 — мій jev-latest уже не той
🔥 — нарешті модель, яка не генерує текст

#agents #Jev

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

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

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

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

⏺Спершу вимоги, план і задачі — потім код: Spec Kit, Kiro, BMAD, GSD, MoAI-ADK, Gangsta Agents.
⏺ Оновлюють специфікацію разом зі змінами в наявному коді: OpenSpec, Spec Kitty.
⏺ Вчать агента правил роботи замість етапів: Superpowers, Matt Pocock skills, GRACE.
⏺ Перевіряють реалізацію за планом або критеріями приймання: Traycer, Memex.
⏺ Перезапускають агента, доки задача не закриється: Ralph Loop, Smart Ralph, GAAI.
⏺ Запускають кількох агентів одночасно, кожного в окремій копії репозиторію: Conductor, Frame, Zenflow.

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

21 жовтня GitHub Next і Microsoft Research показали Proof-Driven Development Kit: він формально доводить, що код агента має властивості, задані у специфікації, — але не те, що сама специфікація правильна. Поки це дослідницьке прев’ю для Rust.

У наступних постах порівняю ці групи за чотирма критеріями — час на фічу, IDE, робота з наявним кодом, перевірка.

👍 — уже користуюсь SDD-фреймворком
👀 — поки працюю без нього
🔥 — чекаю серію

#SDD #SpecDrivenDevelopment

Який процесний SDD-фреймворк обрати: Spec Kit, Kiro, BMAD, GSD Core, MoAI-ADK чи Gangsta Agents

Порівняв усі шість за 4 критеріями:

⏺ Час на фічу.
⏺ Підтримка IDE та AI-агентів.
⏺ Робота з наявним кодом.
⏺Перевірка результату.

Це пост 2 із 5 у серії про SDD-фреймворки (перший тут).

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

Spec Kit від GitHub

⏺Час на фічу: повний цикл — конституція проекту, специфікація, план і задачі. Для багів є коротший процес.
⏺IDE та агенти: працює з більшістю популярних AI-агентів.
⏺Наявний код: є окремі інструкції.
⏺Перевірка: чеклісти й аналіз узгодженості артефактів.

Kiro від AWS

⏺Час на фічу: агент сам пише три артефакти — вимоги, дизайн і задачі.
⏺IDE та агенти: лише власна IDE та CLI.
⏺Наявний код: будує специфікації з наявної кодової бази.
⏺Перевірка: хуки запускають тести після зміни файлів.

BMAD

⏺Час на фічу: залежить від задачі — нечітку ідею спершу уточнюють, дрібну правку одразу реалізують і перевіряють.
⏺IDE та агенти: Claude Code, Codex та інші.
⏺Наявний код: є окремий сценарій.
⏺Перевірка: рев’ю та повторні цикли вдосконалення.

GSD Core

⏺Час на фічу: найлегший процес — Plan → Execute → Verify.
⏺IDE та агенти: Claude Code, Codex, Cursor, Copilot, Windsurf та інші.
⏺Наявний код: команда /gsd-onboard.
⏺Перевірка: окремий етап Verify перед завершенням роботи.

MoAI-ADK

⏺Час на фічу: найсуворіший процес — SPEC → аудит → TDD.
⏺IDE та агенти: лише поверх Claude Code.
⏺Наявний код: спершу characterization-тести фіксують поточну поведінку, потім агент вносить зміни.
⏺Перевірка: гейт TRUST 5 на кожну зміну — лінт, типи й тести, а «тести пройшли» зараховується лише з реальним виводом.

Gangsta Agents — мій фреймворк

Чому я додав власний інструмент до порівняння?

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

Рішення: Рішення: ще до специфікації Gangsta Agents проводить фазу
Grilling — агенти шукають слабкі місця ідеї й аргументи проти неї.

Проект уже включили до незалежного каталогу awesome-ai-plugins.

⏺Час на фічу: найдовший — шість фаз, серед них Grilling, із підтвердженням людини на кожній.
⏺IDE та агенти: Claude Code, Cursor, Codex, OpenCode, Gemini CLI, Copilot.
⏺Наявний код: перша фаза — розвідка кодової бази й вимог.
⏺Перевірка: спершу червоний тест, який падає, і лише потім код, що його проходить.

Що обрати?

• GSD Core — якщо потрібен компактний процес із плануванням, виконанням і перевіркою.
• BMAD — якщо процес має адаптуватися до масштабу задачі.
• MoAI-ADK — якщо важливі TDD і формалізовані вимоги до якості.
• Kiro — якщо команда працює в екосистемі AWS.
• Spec Kit — якщо потрібен структурований процес для різних AI-агентів.
• Gangsta Agents — якщо важливо перевіряти не лише код, а й саму ідею до того, як вона стане специфікацією.
Перевірка ідеї теж коштує часу: агенти сперечаються ще до початку реалізації. Але іноді це дешевше, ніж швидко побудувати не те, що потрібно.

🔥 — уже користуюся SDD-фреймворком
👀 — ще обираю
😁 — пишу специфікацію просто в чаті й поки вистачає

#SDD #SpecDrivenDevelopment

Як встигати за агентами, коли вони працюють більше за людей: 6 практик зі звіту Anthropic

Anthropic опублікувала звіт про те, як змінюється робота всередині компанії. У серпні агенти відпрацювали в 6 разів більше годин, ніж люди, які ними керують.

Кілька цифр зі звіту:

⏺Кількість комітів на інженера зросла приблизно вп’ятеро за пів року. Код агентів видаляють і відкочують не частіше, ніж код, написаний людьми.
⏺Частка джунів серед технічних наймів упала з 27% до 9%.
⏺Близько 80% часу інтерактивних сесій агенти проводять в очікуванні відповіді людини.

Що роблять в Anthropic, щоб встигати за агентами:

1) Пояснили агенту щось удруге — запишіть це в інструкції.

Один зі співробітників сформулював правило так: якщо робиш щось удруге, подумай, як не робити втретє. За рік кількість постійних письмових інструкцій для агентів у компанії зросла з кількох сотень до 8 500.

2) Доручайте одному агенту перевіряти іншого.

Замість того щоб самостійно читати весь вивід, розбийте роботу між кількома агентами: один виконує завдання, інший перевіряє результат. На координацію роботи агентів припадає дедалі більше часу: частка таких сесій зросла з 10% до 22%.

3) Заведіть агента-диспетчера.

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

4) Створіть дашборд замість того, щоб читати всі логи.

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

На другій картинці — чеклист для PR від агента: 4 перевірки, які варто автоматизувати, і 4, де потрібне рішення людини.

5) Регулярно переглядайте роботу агентів та їхні інструкції.

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

6) Записуйте рішення там, де агент зможе їх знайти.

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

І ще один сигнал: на співбесідах в Anthropic згадки про вміле використання AI-інструментів у технічних кандидатів потроїлися, а в нетехнічних — зросли вчетверо. Варто вміти пояснити, яку рутину ви делегували агентам і як перевіряєте їхню роботу.

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

Де прокачати кожен пункт:
1. Інструкції для агентів — CLAUDE.md і auto memory, а для Codex і Cursor — стандарт AGENTS.md
2. Агент перевіряє агента — Code Review у Claude Code, мультиагентне рев’ю PR
3. Агент-диспетчер — субагенти й команди агентів, патерн orchestrator-workers від Anthropic
4. Дашборд замість логів — моніторинг Claude Code через OpenTelemetry
5. Перегляд інструкцій — звіт про невикористані скіли й /usage по скілах
6. Записані рішення — Architecture Decision Records, формат на одну сторінку
7. Усе разом на практиці — ololo: задачі з AI-суддями, сесії агентів із перевіркою по ходу