Дуже захопливо. Тепер ви можете виконувати дикі речі, які може робити Claude Code, локально на вашому комп'ютері прямо в Claude Desktop. Величезний. Відкриє силу Claude Code для набагато більшої кількості людей. (І дуже круто, що вони посилаються на мій пост на CC у своєму оголошенні, дякую команді @AnthropicAI)

Мої найбільші висновки з @Aish_Reganti та @KiritiBadam щодо створення успішних корпоративних AI-продуктів: 1. Продукти ШІ відрізняються від традиційного програмного забезпечення двома основними аспектами: вони недетерміновані, і вам потрібно постійно компрометувати агентність і контроль між ними. Традиційні процеси розробки продукту ламаються, коли ваш продукт дає різні відповіді на одні й ті ж введення і може діяти самостійно. 2. Компроміс між агентством і контролем є основним дизайнерським рішенням у кожному продукті ШІ. Айш і Кіріті подають це як спектр: з одного боку, ШІ діє автономно з мінімальними обмеженнями; з іншого — система суворо обмежена чіткими правилами та воротами «людина в циклі». Більшість успішних корпоративних AI-продуктів займають щось посередині, динамічно коригуючи контроль на основі оцінок довіри, контексту та ризику. 3. Більшість збоїв продукту ШІ виникають через помилки виконання, а не через обмеження моделі. Айш і Кіріті бачать, що команди звинувачують базову LLM, коли справжня проблема — це невизначений обсяг продукту, відсутність обмежень або погане залучення користувачів. Модель, яка бачить галюцинації у 5% випадків, все одно може забезпечити чудовий продукт, якщо ви спроектуєте UX так, щоб відображати оцінки впевненості, дозволяти користувачам перевіряти результати та обмежувати завдання. Практична інсайт: перед тим, як просити кращу модель, проведіть аудит дизайну продукту, оцінювання та потоків користувачів. Дисципліна виконання у більшості випадків переважає продуктивність моделі. 4. Ваш продукт V1 AI має вирішити вузьку, цінну проблему з жорсткими огорожами. Команди зазнають невдачі, намагаючись створити універсального асистента або агента з першої спроби. Виберіть один робочий процес, автоматизуйте одне повторюване завдання або добре відповідайте на одну категорію питань. Вузький діапазон дозволяє збирати сфокусований зворотний зв'язок, швидше налаштовувати модель і доводити її цінність перед розширенням. Широта з'являється пізніше, коли ви ідеально пройшли основний цикл. 5. Спостережуваність і логування є важливішими для продуктів ШІ, ніж для традиційного програмного забезпечення, оскільки поведінка ШІ є недетермінованою і складнішою для налагодження. Варто фіксувати не лише помилки, а й оцінки довіри моделі, характеристики введення, корекції користувачів і метрики затримки. Коли щось іде не так у виробництві, ці журнали — єдиний спосіб відтворити те, що бачила модель, і чому вона прийняла певне рішення. Інвестуйте в лісозаготівельну інфраструктуру раніше, до кризи. 6. Оцінювання необхідні, але недостатні. Оцінки допомагають вимірювати продуктивність моделі на відомих тестових випадках, але вони не відображають повний досвід продукту, крайні випадки виробництва чи задоволеність користувачів. Команди, які покладаються виключно на оцінки, випускають продукти, які добре проходять тестування, але зазнають невдачі в реальному режимі. Поєднуйте оцінки з безперервним моніторингом, циклами зворотного зв'язку користувачами та інструментами спостереження, щоб виявити, що автоматизовані тести пропускають. 7. «Безперервне калібрування» замінює традиційні ітеративні цикли розробки продукту. Оскільки моделі ШІ змінюються, а очікування користувачів змінюються, команди постійно змушені вимірювати реальну продуктивність і коригувати підказки, обмеження або версії моделей. Айш і Кіріті рекомендують інструментувати продукт так, щоб збирати відгуки користувачів і моделювати результати з першого дня, а потім переглядати ці дані щотижня. Без постійної калібрування ваш продукт ШІ буде безшумно деградувати, а користувачі будуть працювати ще до того, як ви це помітите. 8. Безперервне впровадження ШІ означає оновлення моделі та швидкі зміни у вигляді коду, а не ручних втручань. Традиційне програмне забезпечення розгортає код; Продукти ШІ розгортають код плюс зваження моделей, підказки та логіку пошуку. Айш і Кіріті виступають за розгляд підказок і конфігурацій моделей як версійних артефактів у вашому CI/CD конвеєрі з автоматизованими регресійними тестами через оцінки. Це запобігає поширеній антипатерні, коли менеджери менеджерів налаштовують підказки в інтерфейсі та порушують виробництво. Перевага: можна безпечно ітерувати поведінку моделі і миттєво скасувати погані зміни. 9. Продукти ШІ зазнають невдачі, бо команди недооцінюють важливість якості даних. Айш і Кіріті бачать, як команди поспішно налаштовують моделі або додають функції, не перевіряючи попередньо, чи відображають їхні навчальні та оцінювальні дані реальне використання. «Сміття всередині, сміття назовні» стосується ШІ подвійно: якщо ваші дані застаріли, упереджені або не відповідають потребам користувача, жодна кількість підказок чи налаштування моделей вас не врятує. Почніть з того, що налагодьте свій дата-хаус.

Вражаючі