📌 Карта каналу: з чого почати

«Код став чистішим» — це думка. Цифра — доказ. Тут про докази: заміри до/після, агентні інструменти, ціна коду в токенах і open-source зсередини. Без хайпу.

Андрій Кучеренко — мейнтейнер jscpd (3M+ завантажень на тиждень), автор Gangsta Agents і ololo. Чому канал перезапустився у 2026

🔬 Вимірюй, а не вір агентові
⏺ Як виміряти рефакторинг AI-агента на 200 000 рядків (DOU)
⏺ 10 перевірок, що скорочують рев'ю AI-коду
⏺ plugin eval і /skill-doctor: чи працює твій скіл

💸 Ціна коду в токенах
⏺ Token Economics: 4 мільйони токенів на одну задачу (DOU)
⏺ Svelte 598 токенів, React +25%, Angular +38%
⏺ TypeScript: на 31% більше токенів, ніж JavaScript
⏺ TSX на 94% дорожчий за Pug

📐 Spec-driven і Gangsta Agents
⏺ Vibe coding vs SDD: різниця в тому, хто головний
⏺ The Grilling: атака на ідею до першого рядка коду
⏺ 16 spec-driven фреймворків і одна сліпа пляма
⏺ Money Tracker: проект, де агенти не імпровізують

🤖 Агенти: MCP, Skills, безпека
⏺ Викликати — MCP, вирішувати — Skill, забороняти — tool layer
⏺ MCP Apps: сервер віддає інтерфейс
⏺ GitSpawn і Plugin4Shell: як закритися за 5 хвилин

🧭 TS-фреймворки для агентів
⏺ Vercel AI SDK — базовий шар
⏺ LangGraph.js — граф замість ланцюжка
⏺ Mastra, VoltAgent, eve, Genkit
⏺ Rust-тулінг за вихідні: Biome і Bun

🛠 jscpd і open-source зсередини
⏺ v5 на Rust: з 83 секунд до 3,4
⏺ 5.2: перейменовані копії та --history
⏺ 42% дублів — у бібліотеках скілів для агентів
⏺ Claude for Open Source і Claude for Startups

🎮 ololo — хакатони з AI-суддями
⏺ «Готово, тести проходять» — навіщо з'явився ololo
⏺ Handmade Claude Code: збери агента сам

🎓 Навчання
⏺ 12 треків AI-розробки на JS/TS (PDF)
⏺ 50 безкоштовних AI-курсів — карта серії
⏺ Де ви зараз і куди далі: карта 5 рівнів · Roadmap 2026 (DOU)

Як безкоштовно отримати рік Claude Team і $1 000 на API. Потрібен проект із власним доменом і 10 хвилин.

Anthropic розширила програму Claude for Startups. Ololo прийняли цього тижня, Team уже працює - тож пишу з перевіреного: інвестор не потрібен, проекти соло-розробників проходять, заявка справді займає хвилин десять.

Що дають:

⏺ рік Claude Team, до 5 Premium-місць — до $625/міс
⏺ $1 000 API-кредитів і вищі ліміти; кредити живуть 6 місяців
⏺ офіс-години з Applied AI-командою Anthropic: архітектура, evals, вартість
⏺ до $45K офферів партнерів: ClickHouse $5K, ElevenLabs 12 міс, Granola, Hex
⏺ Founder House, хакатони, мітапи

Як подати:

1. Акаунт у Claude Console.
2. Пошта на домені проекту - Gmail відхиляють, це головна причина відмов.
3. Два речення про те, що будуєте.
4. platform.claude.com/offers/startups-application — більшість рішень за хвилини, решта за 2–3 робочих дні.
5. Офери після схвалення шукайте в Console → Claude Startups, а не в пошті.

Якщо ви в найманій команді — перешліть тому, хто вирішує. Це рік Claude на п'ятьох.

🔥 — планую подаватися
👀 — просто читаю
🤡 — вже отримав

Апдейт до поста про Claude for Startups:

Anthropic поставила на паузу рік Team і $1 000 кредитів. Заявок прийшли сотні тисяч, тепер переглядають усі — навіть схвалені, якщо оффер не активовано. Ми в ololo встигли, Team працює.

‼️Якщо вас схвалили, а оффер ще видно в Console → Claude Startups — активуйте зараз, не чекайте.

Тим часом вже подаюся на наступну програму з серії — Google for Startups Cloud Program, рівень Start: $2 000 кредитів на Google Cloud і Workspace на рік для проектів, у які ще не заходив інвестор.

Як буде результат — напишу, що вийшло, і покрокову інструкцію: що потрібно мати, де відмовляють і як отримати Workspace.

👀 — чекаю інструкцію
🔥 — теж подаюся
🤡 — вже маю

Грант $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