🇺🇦 Math.random(): community of engineers
الذهاب إلى القناة على Telegram
Інженерний AI-канал Андрія Кучеренка, автора https://jscpd.dev. Вимірюю, що зробив AI-агент. Рахую ціну коду в токенах. Розбираю MCP, Skills, SDD. @andrey_pk x.com/a_kucherenko linkedin.com/in/andrey-kucherenko youtube.com/@mathrandomjavascriptcommunity
إظهار المزيد1 304
المشتركون
+124 ساعات
+237 أيام
+3330 أيام
أرشيف المشاركات
Який процесний 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-фреймворком
👀 — ще обираю
😁 — пишу специфікацію просто в чаті й поки вистачаєЯк перевіряти код агента, не читаючи кожен PR: 8 практик команди Claude Code
Коли код пише AI-агент, перевірка коду стає окремою проблемою. У команді Claude Code близько 90% коду пише сам Claude. За літо вони стали зливати вдвічі більше PR, а відкочувати — на 40% менше. Мета в них проста: витрачати менше людського часу на кожен PR і не збільшувати кількість відкатів.
Ось вісім корисних практик з їхнього процесу, які можна повторити у власному проекті. Я сам ганяв агента по проекту на 200 тисяч рядків, тому знаю: перевірка має встигати за розробкою.
1) Вимагайте доказів, що код працює: перед «готово» агент запускає тести й збірку або перевіряє інтерфейс і показує результати. Зафіксуйте це правило в
CLAUDE.md.
2) Не перетворюйте CLAUDE.md на документацію до всього проекту: лишіть стек, правила, цілі й обмеження, а докладні інструкції винесіть в окремі файли.
3) Створіть REVIEW.md з правилами перевірки: які помилки шукати, що можна пропустити, які проблеми критичні та які докази має наводити перевіряльник.
4) Перевіряйте код ще до PR: запускайте /code-review і /security-review або доручіть субагенту з чистим контекстом, який не писав цей код.
5) Не залишайте відкритих зауважень перед злиттям: знахідку треба виправити або обґрунтовано закрити, зокрема якщо це хибне спрацювання.
6) Визначайте людське рев’ю за ризиком: малоризикові правки від довірених авторів зливаються після автоматичних перевірок, середній ризик схвалює одна людина, високий — дві.
7) Перетворюйте інциденти на перевірки: з’ясовуйте, чому система пропустила помилку, і додавайте такі випадки до набору, на якому щодня оцінюють перевіряльника.
8) Почніть з одного репозиторію: підключіть автоматичне рев’ю, відточіть правила на реальних PR і лише потім поширте далі.
Я б почав з пунктів 1, 3 і 4: критерії готовності, правила рев’ю і перевірка до PR.
🔥 — візьму ці практики у свій процес
👀 — у нас код теж перевіряє агент
😱 — у нас увесь код досі перевіряють людиЯк я працюю з 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-фреймворком
👀 — поки працюю без нього
🔥 — чекаю серію
Аліас
-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-агент може вимкнути моніторинг і... сказати, що нічого не чіпав))
Це два випадки з офіційного звіту 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. Тепер тиша
🔥 — йду дивитися, хто має доступ до алертів
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 без тестів
Ваш 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Як перевірити, що агент справді переніс код. 4 кроки, будь-яка пара мов 👇
1. Один раз завантажити модель:
npx jscpd --semantic-download
2. Порівняти старий і новий код:
npx jscpd --compare path/to/old path/to/new
3. Подивитися, де відповідник кожної функції: новою мовою — переїхала, лише старою — ще ні, ніде — загубилася.
4. Якщо переносить агент, дати йому скіл:
npx skills add kucherenko/jscpd --skill code-migration
Він переносить спершу тести, потім по одній функції й після кожного кроку перевіряє себе.
Що очікувати: перший запуск довший, далі — секунди, бо вектори кешуються. Залежності й результати збірки (node_modules, target) краще винести в --ignore, інакше jscpd порахує і їх.
Розбір з експериментом: https://jscpd.dev/blog/when-code-clones-matter
🔥 — спробую на своєму проекті
👀 — збережу на потім▶️ У ololo тепер є YouTube-канал
Перше відео — хвилина живої гри: двоє гравців, одна сесія, термінал, табло, вердикти AI-суддів і переможець.
ololo — це живі хакатони для тебе і твого AI-агента.
Береш Claude Code, Codex чи свого агента, проходиш задачі на час, а AI-судді розбирають, як ви з агентом розв'язали задачу, і показують, що змінити в промптах.
Скоро там будуть записи живих ігор з моїми коментарями. А першу гру можна зіграти вже зараз, безкоштовно: ololo.dev
▶️ Відео: https://youtu.be/gsi_Es9Qy68
▶️ Канал: https://www.youtube.com/@ololo-dev
Дякую за підтримку)
Корисне для авторів AI-спільнот від Мінцифри та AI HOUSE 🇺🇦
Вони створюють національну платформу AI-спільнот. Додайте туди свій канал, і вас знайдуть ті, хто шукає, де вчитися й спілкуватися про AI: побачать, чим ви займаєтеся, і зможуть прийти на ваші події.
Перший етап уже розпочався: збирають відкритий список активних спільнот, тож можна потрапити в нього з самого старту.
Підійде, якщо ви пишете про AI, агентів чи розробку з LLM, регулярно щось проводите, відкриті до нових людей і ділитеся знаннями.
🔗 Подати свій канал: https://form.typeform.com/to/OhpQIWm4
🔥 - корисно, веду свій канал
👀 - просто читаю
13 років боротися з дубльованим кодом, а тепер шукати його навмисно. Навіщо?
Розповідаю: коли ШІ-агенти переносять код на іншу мову, саме дублікат між старою і новою версією показує, що код справді переїхав. Тож мій детектор copy-paste став аудитором міграцій.
Під час міграції стара логіка має знову з'явитися в новому коді: як відповідник, що робить ту саму роботу новим синтаксисом.
⏺Відповідник є новою мовою — функція переїхала.
⏺Є лише старою мовою — її ще не перенесли.
⏺Немає ніде — щось загубилося.
Той самий сигнал, протилежне значення. Усе залежить від того, що ти хочеш довести.
Повний розбір з експериментом fs-extra → Rust: https://jscpd.dev/blog/when-code-clones-matter
А ви вже переносите код за допомогою ШІ-агентів?
👍 — так, переношу
👀 — поки ні
Грант $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 мені б не завадили
Інструкція «Як виміряти рефакторинг агента на своєму репозиторії»
7 кроків — збережіть, знадобиться, коли агент скаже «код став чистішим».
1. Зафіксуйте версію інструмента. «До» і «після» порівнювані лише на одній версії: голий npx jscpd може підхопити закешовану стару, а вона рахує інакше.
npx jscpd@5.3.1 --health --reporters ai .
2. Зніміть baseline у чистому чекауті, без локальних файлів. Запишіть health і три субоцінки: duplication, dead-code, complexity. Найнижча з них — це місце, куди йти першим.
3. Поставте скіл, який задає процедуру, а не побажання:
npx skills add https://github.com/kucherenko/jscpd --skill codebase-refactoring
4. Промпт — чотири речі й жодного прикметника: зробити рефакторинг за скілом, прогнати jscpd --health до й після, описати результат, задокументувати перебіг. «Зроби код чистішим» — не інструкція, бо в ній немає міри.
5. Цикл, який має тримати агент: тести навколо коду, який чіпає (немає — спершу характеризаційні) → один крок — одне перетворення → тести → окремий коміт → свіжий замір у чистому git worktree. І знову.
6. Перевіряйте докази, а не звіт. Після кожного коміту: оцінка зрушила? тести зелені? білд збирається? модулі імпортуються? Кожну знахідку dead-code агент має підтвердити кодом, а не видаляти заради числа: в моєму проході 596 знахідок лишились на місці, а оцінка все одно зросла з 86 до 95.
7. Знайте, де зупинитись. cx не впав — код просто переїхав. Файл без тестів — не чіпати, поки їх немає. У мене агент зупинився перед middleware на 6 388 рядків — і це було правильно.
Що очікувати: перший прохід дорогий — на 200 000 рядків це 12 комітів і 50 (D) → 61 (C). Далі той самий замір запускається після кожної зміни агента, і рефакторинг тримайте окремо від фічевих дифів.
Повний розбір з таблицею по кожному коміту — у статті на DOU: https://dou.ua/forums/topic/62369/
🔥 — зберіг
👀 — перешлю тімліду
👏 — вже так роблюAnthropic дозволила Claude виходити з токсичних діалогів — і визнає, що не знає, чи здатен він страждати.
З 12 листопада набуває чинності оновлена Usage Policy: заборонено тривале й безцільне жорстоке поводження з моделями. Критикувати відповіді, лаятись через баги й тестувати межі — можна. Систематично знущатися без мети — ні.
Механізм уже існує з серпня 2025 року: Claude може завершити розмову як крайній захід, якщо спроби змінити її напрям не допомогли. Anthropic підтверджує його використання і в Claude Code.
Але навіщо захищати AI, якщо невідомо, чи він узагалі щось відчуває?
Під час тестів Claude Opus 4 демонстрував ознаки apparent distress — зовнішні прояви, схожі на страждання, — і за певних умов обирав завершити розмову.
Anthropic визнає: чи мають моделі моральний статус, досі невідомо. Але вирішила запровадити запобіжник на випадок, якщо мають.
Тепер AI-інструмент може припинити діалог не через помилку чи ліміт, а через поведінку користувача.
🔥 — правильно зробили
👀 — зарано, спершу докази
😁 — робот вийшов із чату. Буквально.
Хто хоче книгу в подарунок?
📙 @devshive розігрує «Комп'ютерні мережі» Т. Коробейнікової та С. Захарченка — український підручник про той фундамент, без якого половина речей у бекенді здається магією. Підтримую ініціативу.
Без ботів, без «підпишись на 10 каналів». Просто написати «network» і нік під дописом. Розіграш у середу, 15 жовтня. Доставка — лише по Україні.
Якщо у вас на полиці лежить прочитана технічна книга — можливо, варто зробити так само☺️
👉 https://t.me/devshive/293
Апдейт до поста про Claude for Startups:
Anthropic поставила на паузу рік Team і $1 000 кредитів. Заявок прийшли сотні тисяч, тепер переглядають усі — навіть схвалені, якщо оффер не активовано. Ми в ololo встигли, Team працює.
‼️Якщо вас схвалили, а оффер ще видно в Console → Claude Startups — активуйте зараз, не чекайте.
Тим часом вже подаюся на наступну програму з серії — Google for Startups Cloud Program, рівень Start: $2 000 кредитів на Google Cloud і Workspace на рік для проектів, у які ще не заходив інвестор.
Як буде результат — напишу, що вийшло, і покрокову інструкцію: що потрібно мати, де відмовляють і як отримати Workspace.
👀 — чекаю інструкцію
🔥 — теж подаюся
🤡 — вже маю
Як безкоштовно отримати рік 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 на п'ятьох.
🔥 — планую подаватися
👀 — просто читаю
🤡 — вже отримав
📌 Карта каналу: з чого почати
«Код став чистішим» — це думка. Цифра — доказ. Тут про докази: заміри до/після, агентні інструменти, ціна коду в токенах і 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)
