fa
Feedback

فریب کلاهبرداران را نخورید! تل‌متریو این کانال‌ها را شناسایی و برچسب‌گذاری می‌کند 👉 برای مشاهده برچسب، اشتراک تهیه کنید

🇺🇦 Math.random(): community of engineers

🇺🇦 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. Тепер тиша 🔥 — йду дивитися, хто має доступ до алертів

sticker.webp0.14 KB

sticker.webp0.14 KB

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 розігрує «Комп'ютерні мережі» Т. Коробейнікової та С. Захарченка — український підру
Хто хоче книгу в подарунок? 📙 @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 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)