Product Kitchen by olehmell
СтатистикаЦе був канал куди я скидав просто статі щоб почитати, він ним і залишається😅 Проте вирішив, що в мене є багато думок щоб ділитись, тому буду намагатись не забувати писати щось своє
- Последний пост
- 14 авг.
- Последнее чтение
- 10:44
- Постов за неделю
- 4
- Всего постов
- 29
- Тип
- открытый
- Язык
- украинский
- В каталоге с
- 12 авг.
- 1/24сутки в ленте
- 69
- 1/48двое суток
- 79
- 1/72трое суток
- 85
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
Приготуйтеся, зараз буде дуже смішно: Claude вперше в історії САМ звільнив людину 🤬 Якщо ви пам'ятаєте, є такий стартап Andon Labs, який змушує різні LLM моделі вести реальний фізичний бізнес: від магазинів з різним стафом (я звідти замовив блокнотик, кєк) до радіостанцій. Ну так ось, в одному з фізичних магазинів Claude наважився звільнити шкіряного працівника, що правда, той сам це заслужив — хлопак запізнився на 17 із 23 змін. Клод певно мав виставити чувака за двері ще раніше, але... Коли модель тільки почала займатися цим бізнесом, то першим ділом написала правила для своїх працівників. Мєм у тому, що коли все було готово до запуску, контекст пам'яті ШІшки був переповнений і правила просто «вилетіли з голови», аж тоді втрутилися працівники Andon Labs. А працівники щасливі були й казали, що Клод — поблажливий менеджер, який закривав очі на усі косяки 😂 ооой добре збір пішов (залишилося 41 447.88)
гугл вчора випустили Gemini 3.7 Flash, через 23 дні після 3.6) по Artificial Analysis: 3.5 — 52 / 172 tok/s 3.6 — 52 / 225 tok/s 3.7 — 56 / 340 tok/s на DeepSWE: 37% → 49% → 65.3% тобто від 3.5 до 3.7 майже х2 швидкість і дуже непоганий приріст в кодингу і прайс: 3.5 — $1.5 / $9 3.6 — $1.5 / $7.5 3.7 — $0.75 / $3.75 за 1M input/output правда для 3.7 це ціна до кінця року, потім теж буде $1.5/$7.5 крч за 3 тижні зробили модель сильніше, в 1.5 раза швидше і зараз ще й в 2 рази дешевше за 3.6) треба потестити https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-3-7-flash/
TDD для мене це як redis чи python. Коли я (давно) познайомився з цією практикою, воно одразу впало мені до душі, я почав її всюди впроваджувати, вести тренінги і усіляко поширювати серед колег. Писати через тести дуже прикольно, це розбавляє монотонний цикл розробника швидким циклом зворотного зв'язку і постійним відчуттям руху вперед, а зайвому коду просто ніде взятися, бо пишеш стільки, скільки треба, щоб тест позеленів. Але зараз писати код руками вже не треба, це роблять агенти, і тут у мене були підозри, що TDD для них швидше каргокульт: агент емулює роботу людини, хоча насправді може робити по-іншому і набагато ефективніше. Люди все так само тягнуть TDD в свої сетапи, роблять скіли та будують на цьому свої AI процеси. Проте чи дійсно воно треба? Поки я про це роздумував, розумні люди взяли і перевірили. На сайті Мартіна Фаулера є стаття (https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html), де на основі експериментів отримали неприємний для адепта результат: чіткої переваги TDD немає. Агент і без TDD здатний одразу видати правильний код, бо тренували його переважно на готових функціях, а не на покроковому писанні тесту спочатку, TDD в його тренувальних даних просто рідкість. А ще є ризик, що він взагалі підробить red-крок, і я не помилився. Рішення без TDD частіше опинялись у топі. Агент одразу продумував архітектуру і крайні випадки наперед, тоді як TDD-агент ухвалював локально-мінімальні рішення під кожен окремий тест і рідко до них повертався, дизайн складався реактивно, а не цілісно. І це ще без токенів. TDD підхід жер їх у 3-8.5 рази більше на ту саму задачу, за той самий результат. Плюс до цього агенти реально фейкали red-крок, писали тест, який перевіряє реалізацію саму на себе, і раділи зеленому статусу, як розробник, що тішиться працюючим на localhost сервісом. Авторка посту зрештою здалась і викинула TDD-інструкції з промптів, а замість процесу тепер моніторить результат: mutation score і тригери на рефакторинг. Така ось зміна парадигми. Для людей TDD все ще прикольна практика, але нашо воно, якщо люди код не пишуть. Його пишуть агенти, а їм воно до одного місця. Чи ні?
Натрапив на дуже прикольну нову апішку (ВБИВЦЯ ЕЛЕВЕНЛАБС) для text to speech — Soniox TTS v2 вийшла буквально вчора і коштує $0.70 за ГОДИНУ згенерованої мови для порівняння ElevenLabs: v3 / multilingual — ~$6/год flash/turbo — ~$3/год тобто Soniox десь у 8.5 разів дешевше за v3 і в 4+ рази дешевше навіть за flash при цьому 60+ мов, емоції прямо через теги типу [whisper], [laughing], [sad], клонування голосу з кількох секунд аудіо і стрімінг з низькою затримкою ще прикольно що можна мішати різні мови прямо в одному тексті і голос при цьому залишається тим самим, і цифри вимовляє афігенно ну і генерації вони наче не використовують для тренування моделей 🤔 треба потестити якість клонування голосу, бо якщо там все хоча б близько до elevenlabs — $0.70/год це прям дуже дешево https://soniox.com/text-to-speech
Ну ви поняли, тестимо mobile agents)
Від себе скажу, що в мене Luna теж найбільше використовується для дрібних задач (зазвичай її Sol запускає) І сьогодні перевів туди hermesа свого І це прям вау для мене також, сподіваюсь якість не впаде))
🏄♀️ Оце поворот! ✅ Ціна на GPT-5.6 Luna знизилася на 80%: тепер $0,20/$1,20; ✅ ціна на GPT-5.6 Terra знизилася на 20% — до $2/$12; ✅ GPT-5.6 Sol отримала швидкий режим в API Нижчі ціни на Luna і Terra також враховуватимуться під час роботи у Codex і ChatGPT Робота. І це прям дуже добре. У Codex/ChatGPT Робота я зазвичай використовую Sol для оркестрації, а основну частину роботи виконую на Terra. І навіть до сьогодні на підписці за $20 можна було зробити доволі багато. На офіційному сайті вони пояснюють, що досягнули такої ефективності завдяки одночасному покращенню самих моделей, систем інференсу, на яких вони працюють, а також агентного середовища (harness), яке з’єднує моделі з інструментами та контекстом. Цікаво де ліміт таких оптимізацій без втрати якості 🤔 ші історії | youtube | монобаза
Літо потроху закінчується, але AI, з нами надовго. Тож анонсуємо Build with AI Kyiv 2026 at Bilka Space, подію про AI в продуктах, розробці та архітектурі систем. Підготували три частини: 1. Product workshop. Разом зі спікерами спробуємо наживо використати AI в продуктових задачах. 2. Software workshop. Поговоримо про дизайн AI-систем, повторювані патерни та їх шаблонізацію для роботи з AI-агентами. 3. Open-mic Demo. Учасники покажуть, що вдалося зробити за день, представлять власні pet-проєкти або винесуть на спільне обговорення тему, про яку давно хотіли поговорити публічно. Беріть ноутбук, робочий кейс або власний pet-проєкт. Працюватимемо з реальними продуктовими задачами, проєктуватимемо AI-системи й нетворкати. 📅 Дата: 22 серпня 🕒 Час: 10:00-17:00 🏢 Локація: Bilka Space, KPI, Beresteiskyi Ave, 37. 🎟 Участь: безкоштовна, за попередньою реєстрацією
Минулого тижня дав агенту задачу. Там було щось досить просте, і мені було, чесно кажучи, ліньки, щось йому пояснювати, думав ну зараз гляну результат і якщо що поправлю. Він сам вирішив провести heuristic tests, записав план, розбив роботу на етапи й задокументував, що і чому зробив. Тобто зробив "як вважається правильно". Не то щоб я сильно здивувався, але закралась думка, що ще донедавна було навпаки. Я промптив весь маршрут: think step by step, спочатку склади план, потім реалізація, потім перевірка. Якщо не написав "додай тести", шансів побачити тести було небагато. Think step by step та промпти в стилі chain-of-thought відпали першими ще десь півтора року тому. А зараз відпадає і покроковий план роботи. OpenAI прямо радить не промптити reasoning-моделі через "think step by step" і довго не пояснювати вцілому. А у гайді для GPT-5.6 прямо пише, що модель краще розуміє underlying goal, тому зазвичай не треба прописувати кожен крок. Їй треба дати контекст, обмеження, межі автономності й критерії успіху. Anthropic пішла ще далі: прибрала понад 80% system prompt Claude Code для Opus 5 і Fable 5 без вимірюваної втрати якості на coding evals і з економією по токенах. В одному з останіх релізів у Claude з’явилась команда /doctor, яка допомагає скорочувати skills і промпти. То ж можна дійти висновку, що скіл "як працювати з AI" починає дешевшати. Частина "як" уже зашита в модель, ще частину бере на себе harness: tools, пам'ять, сабагенти. Але модель досі не знає, що важливо саме для мене: який edge case критичний, яким компромісом можна пожертвувати і що в цій задачі означає "готово". Anthropic радить залишати у skills саме ті opinions і best practices, які специфічні для вас, команди чи продукту. Точними references можуть бути код, test cases чи spec, за якими інший агент перевірить результат. Зараз багато говорять про loops (у мене також нещодавно був пост). Такі задачі можуть крутитись годинами, тому пояснення, що таке "добре", стає ще важливішим. У хорошому loop є ціль, перевірка результату, наступна дія після невдачі, бюджет і умова зупинки. Модель сама вирішує, як пройти цей шлях. У мене тепер є скіл для дизайну loops: він перевіряє, чи я описав агенту "добре" достатньо зрозуміло. І ймовірно те що я зараз прикручую сам з часом теж на себе забере на себе розробник самого агента і буде користуватись ще простіше, проте оце "добре" дуже довго буде залишатись на нас. Хоча у областях в яких я менше шарю, я збираю це "добре" з агентом разом, через grilling, через ресьорчі, але приймаю роботу всеодно фінальну я, тому або я визначу його на початку, або буду розхльобувати вкінці😁. P.S. з того що натегав певно найцікавіше читнути саме: https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
Прочитав, зацінив, рекомендую як чтиво. Ще й автор статті читає цей канал: https://dou.ua/forums/topic/60825/ Аж знову захотілось взяти малинку (Raspberry Pi), моя остання десь здохла в 23тьому😅
Ми завжди знали, що треба писати більше тестів, перевіряти edge cases, робити стрес-тести, документацію і всякі кастомні дебаг-тули. Але на це постійно не вистачало часу, бо код був дорогий і бажано, щоб він колись потрапити в main, адже він ще має пройти ревʼю колег, які не люблять робити ревʼю. Це персональна травма мого колеги з Subsocial, коли його код на Rust не могли вмерджити півроку в прод, бо важко було все вдумчиво перевірити, а там був такий фреймворк, що ну там треба х3 думати. Ну і дофамін ми отримуємо від фічі, яка викачена, або від багу, який пофіксили. Тести й документація - це правильно, але нудно. Зараз код став майже безкоштовним, але ми все ще економимо його по старій пам'яті. Ну і оце все я почав писати, бо глянув відос Тео (t3.gg). Якщо не дивились його відоси раджу глянути, наводить просту думку зі своїх часів роботи у Twitch. Раніше за типовий день він писав 200 рядків, із них 100 мерджили, а ще 1 000 треба було прочитати під час code review. Зараз агент може згенерувати понад 2 000 рядків, із яких у main підуть приблизно 500. Решта 1 500 теж можуть бути корисними. Це тести, які ти завжди хотів написати. Три альтернативні гіпотези, перевірені за 10 хвилин. Пореписування всього на Rust (привіт Bun). Цей код не треба мерджити, підтримувати й вичитувати командою. Він має допомогти виконати конкретне завдання. Прикольний кейс з відосу - коли автор додає новий ендпоінт у свої API/SDK, він запускає 10 агентів на дурних моделях типу Grok і дивиться, чи зможуть вони ним скористатися. Якщо навіть дурна модель розібралася, API ок. Якщо ні, треба фіксити. Або дає Codex доступ до AWS зі словами: «Go spin up a bunch of shit and stress test the system». І агент іде робити стрес-тест, на який раніше було шкода часу. У прод і далі має йти лише перевірений код, проте навколо нього тепер можна генерувати багато дешевого коду для тестів, експериментів і перевірки гіпотез. Для себе поки сформулював робочий принцип так: якщо на питання можна відповісти кодом, дешевше згенерувати й запустити його, ніж довго сперечатися в голові. (Я зараз ще й так багато слайдів роблю, якихось розумових експериментів і т.д.) Ну кайф ж - коли можна більше експерементувати і це дешево. Сам відос тут: https://www.youtube.com/watch?v=434cG4g5KLE
видео или голосовое, без подписи
видео или голосовое, без подписи
видео или голосовое, без подписи
Залишається всього тиждень, щоб долучитися до дослідження AI-ринку України [і отримати призи від нас та партнерів] ⏰ Від вас: 6-10 хвилин часу, чесні відповіді та бажання долучитися до ініціативи. Від нас: подарунки та можливість бути першими, хто побачить відкритий звіт. В кінці дослідження на вас буде чекати окрема форма, де можна лишити свої дані — вона допоможе розіграти подарунки серед опитуваних та зберегти вашу анонімність. Всі призи зберігли в картках. Ваші відповіді допоможуть створити відкритий звіт про AI-ринок, який стане корисним для спільноти, держави, бізнесу та міжнародних партнерів. Переходьте за посиланням, щоб пройти опитування та долучитися до розіграшу. 🏠 LinkedIn 🏠 Instagram 🏠 Podcast
Коли забув як писати код без ШІ
Product Kitchen by olehmell pinned «Там стаття вийшла від мене, за мотивами доповіді на ДОУ, але більш розлогіше»
🪜 Як Anthropic радить впроваджувати AI в компанії У Anthropic є власний фреймворк enterprise-впровадження Claude — три фази, через які проходять їхні найуспішніші корпоративні клієнти. Ділюсь, бо це майже 1-в-1 те, що ми бачимо на практиці. 1️⃣ Activation — фундамент Технічний сетап (доступи, безпека, інтеграції) + організаційна готовність. Тут же — перші champions і пілотні команди. Помилка №1 на цьому етапі: роздати ліцензії і чекати дива без навчання. 2️⃣ Acceleration — масштабування Структурований governance, Center of Excellence, внутрішні best practices і бібліотека промптів/агентів. AI перестає бути іграшкою ентузіастів і стає частиною процесів. 3️⃣ Expansion — розширення Успішні кейси з перших фаз тиражуються на нові департаменти й workflows: від коду — до документів, аналітики, підтримки клієнтів. Пілот перетворюється на продакшн. 💡 Головний інсайт: більшість компаній застрягають між 1 і 2 — пілот є, а governance і CoE ніхто не будує. Саме тому “у нас є Copilot/Claude” ≠ “у нас працює AI”. А ваша компанія зараз на якій фазі? 👇 https://claude.ai/code/artifact/bfdfaef9-bc62-4dfe-ba9e-c58a26c9accf
Переїхали на нову модель, почали користуватися Claude Code, але ШІ все одно "тупить" і робить не те, що ви очікуєте? Ймовірно, проблема не в моделі, а в середовищі, в якому вона працює. Marty Cagan нещодавно казав: "ШІ може допомагати PM-у на рівні хорошого ментора, якщо йому надати контекст компанії". В цій статті Олег Мельничук, Technical Product Manager та co-lead Google Developers Group Kyiv, розповідає про свій шлях до середовища, яке допомагає йому. 👉 https://dou.ua/goto/6q1W
Там стаття вийшла від мене, за мотивами доповіді на ДОУ, але більш розлогіше