У 2026 році Андрій Карпаті, колишній керівник AI у Tesla, запропонував підхід до роботи з великими мовними моделями, який різко контрастує з типовою культурою «просто напиши кращий промпт». Підприємець і розробник Остін Марчезе, який будує продукти на базі Claude, розклав цей підхід на три шари. Перший і ключовий з них — це правильно побудована специфікація (spec), яка перетворює людське розуміння задачі на формат, з яким модель справді може надійно працювати.

Цей матеріал зосереджений саме на першому шарі: як створювати високоякісні спеки для Claude за методом Карпаті, чому «план-режим» моделей недостатній і як перейти від поверхневих завдань до справжніх цілей бізнесу.

Автомийка за 50 метрів: як проста задача викриває глибоку проблему AI

Карпаті наводить, на перший погляд, банальне запитання: «Я хочу поїхати на автомийку, щоб помити машину. Вона за 50 метрів. Мені їхати чи йти пішки?» Сучасні моделі впевнено відповідають: «Йти пішки, бо це дуже близько».

Марчезе перевірив це на чотирьох провідних системах — Claude, Gemini, Grok і ChatGPT. Усі порадили йти. Формально логіка виглядає розумною: коротка відстань, отже, пішки. Але в реальному світі це помилка: ціль — не «дійти до автомийки», а «помити машину», а для цього машина має опинитися на автомийці.

Цей приклад оголює фундаментальну рису сучасних моделей. Вони блискуче працюють там, де все можна виміряти й формалізувати: математика, код, чітко структуровані інструкції. Але в задачах, де критичну роль відіграє контекст і приховані передумови, модель не має «сигналу», на який можна спертися. Вона бачить поверхневий опис ситуації, а не глибинну ціль.

У випадку з автомийкою модель «бачить» лише відстань і загальну людську норму: якщо близько — йди пішки. Вона не розуміє, що ключовий об’єкт задачі — не людина, а автомобіль, який має опинитися в точці послуги. Це не дрібна помилка, а симптом: між людським розумінням задачі та тим, що реально «бачить» AI, існує розрив.

Саме цей розрив і має закрити перший шар методу Карпаті — шар специфікації.

Спека як міст між людською інтуїцією та «обчислювальним мозком» Claude

Карпаті пропонує дивитися на сучасні моделі не як на «цифрових співробітників», а як на потужні статистичні симулятори, яким потрібно дуже чітко пояснити, що саме вони мають робити. У цьому контексті «спека» — це не просто розширений промпт, а формалізований перенос вашого розуміння задачі в структуру, яку модель може обробити без небезпечних припущень.

Марчезе описує перший шар методу так: це створення детальної спеки, яка переносить людське розуміння в формат, придатний для Claude. На відміну від «план-режиму» (plan mode), який генерує загальний план дій, Карпаті вважає, що цього рівня абстракції недостатньо. План занадто високорівневий і залишає моделі надто багато простору для інтерпретацій — саме там і народжуються помилки на кшталт «прогулянки до автомийки».

Замість цього пропонується працювати з AI як із «агентом-співавтором спеки»: не просто просити його «спланувати», а разом із ним проєктувати детальну специфікацію. Спека стає тим самим «контрактом», який фіксує:

• що насправді є ціллю;
• які обмеження та контекст;
• які кроки і в якій послідовності мають бути виконані;
• які рішення потребують людського підтвердження.

У цьому підході головне — не красномовність промпта, а точність і структурованість опису задачі.

Від завдання до цілі: чому «зроби звіт» — це погана спека

Ключова помилка, яку Марчезе бачить у більшості користувачів AI, — вони формулюють для моделі завдання, а не цілі. Наприклад: «Створи звіт за підсумками місяця». На поверхні це виглядає як нормальний запит. Але з точки зору методу Карпаті це лише «поверхневе завдання».

Справжня ціль у такому випадку — не сам звіт, а рішення, яке цей звіт має допомогти ухвалити. Чи потрібно скоротити витрати? Чи варто масштабувати рекламну кампанію? Чи доцільно наймати нових людей у відділ продажів? Саме ці питання і є тим, заради чого взагалі створюється звіт.

AI ніколи не зможе самостійно вирішити, яка з цих цілей є вашою. Модель не має власних мотивацій, бізнес-контексту, політики компанії чи розуміння ризиків. Вона може лише оперувати тим, що ви явно сформулювали. Якщо ви даєте їй лише завдання «зробити звіт», вона оптимізуватиме структуру, стиль, візуалізацію — але не те, чи допоможе цей документ ухвалити правильне рішення.

Тому перший крок у побудові спеки — виявити справжню ціль. Не «що треба зробити», а «яке рішення або зміну в реальному світі це має забезпечити». У випадку з автомийкою ціль — «чиста машина», а не «людина біля автомийки». У випадку з бізнес-звітом — «чітке управлінське рішення», а не «красивий PDF на 20 сторінок».

Марчезе пропонує системно вбудувати цей крок у роботу з Claude: замість того, щоб одразу просити модель «зробити X», варто спочатку попросити її провести з вами міні-інтерв’ю.

Claude як інтерв’юер: як витягнути справжню ціль і обмеження

Щоб перетворити розмиту задачу на якісну спеку, Марчезе радить використати Claude як інструмент для «витягування» цілей і контексту з користувача. Ідея проста: перш ніж щось будувати, модель має розпитати вас, що саме ви намагаєтеся досягти.

Замість промпта на кшталт «Створи end-of-month звіт по продажах» варто почати з інструкції: «Проведи зі мною інтерв’ю, щоб виявити ціль цього проєкту, ключові рішення, які мають бути ухвалені на основі результату, і обмеження, в яких ми працюємо». Далі Claude ставить уточнювальні запитання, а ви відповідаєте, поступово розкриваючи:

• які саме бізнес-рішення мають бути прийняті;
• які метрики справді важливі;
• які часові, бюджетні чи регуляторні обмеження існують;
• які приклади «хорошого результату» ви вже бачили в минулому.

У результаті формується не просто опис завдання, а карта цілей і контексту, на якій потім будується спека. Це критично важливо, оскільки модель не здатна «вгадати» ваші справжні пріоритети. Вона може лише структурувати те, що ви їй дали. Інтерв’ю-етап змушує користувача проговорити те, що зазвичай залишається в голові як неявне знання.

Фактично Claude тут виступає не як «виконавець», а як фасилітатор мислення. Він допомагає перетворити інтуїтивне розуміння задачі на явну, структуровану специфікацію. І саме ця специфікація, а не початковий розмитий запит, стає основою для подальшої роботи моделі.

Agile проти waterfall: чому великі промпти ламають навіть найкращі моделі

Ще одна типова помилка користувачів AI — спокуса «скинути все й одразу». Якщо модель здається надпотужною, виникає бажання описати в одному гігантському промпті весь проєкт: від постановки задачі до архітектури, реалізації, тестування й документації. Це класичний waterfall-підхід: одна велика задача, один великий результат наприкінці.

Марчезе називає це «водоспадним» використанням AI і вважає, що саме так більшість людей інтуїтивно намагаються працювати з агентами. Проблема в тому, що кожне припущення моделі на такій довгій дистанції накопичує похибку. Якщо десь на початку вона неправильно інтерпретувала ціль або контекст, уся подальша робота буде побудована на хибній основі.

Альтернатива — agile-підхід до спеки. Замість однієї гігантської інструкції проєкт розбивається на низку невеликих, чітко окреслених підзадач із проміжними контрольними точками. Кожен крок має:

• вузький, зрозумілий обсяг;
• конкретний очікуваний результат;
• момент перевірки й корекції перед переходом до наступного етапу.

У такій моделі Claude не отримує одразу «все й назавжди». Він працює за циклами: специфікація для маленького кроку, виконання, рев’ю, корекція, наступна спека. Це знижує ризик того, що помилка на ранньому етапі зіпсує весь проєкт, і дозволяє людині постійно тримати руку на пульсі.

Марчезе пропонує прямо зафіксувати цю філософію в роботі з Claude: інструктувати модель «зміщуватися» в бік менших, більш відокремлених спек. Тобто не просто розбивати задачу вручну, а просити AI самому пропонувати дрібніші модулі роботи, замість того щоб намагатися охопити все одразу.

У підсумку спека перетворюється на серію компактних «контрактів» між людиною й моделлю, кожен з яких легко перевірити й скоригувати.

«Будь точним і користуйся мозком»: чому AI має змушувати вас думати

Третій елемент першого шару — точність і свідома участь людини. Марчезе наголошує: що точніше сформульована спека, то менше припущень мусить робити модель. А кожне припущення — це потенційна точка відхилення від того результату, який ви насправді хочете отримати.

У практиці це означає дві речі.

По-перше, варто максимально конкретизувати вимоги ще на етапі спеки. Замість «зроби це добре» — чіткі критерії: які розділи, яка структура, які формати даних, які обмеження по часу виконання, які зовнішні залежності. Це не про мікроменеджмент, а про зменшення простору для небезпечних інтерпретацій.

По-друге, користувач не може делегувати моделі відповідальність за зміст самої спеки. Навіть якщо Claude допомагає її писати, людина має критично перечитати документ і зрозуміти, що саме там зафіксовано. Щоб не перетворити цей етап на формальність, Марчезе радить прямо вбудувати в промпт вимогу: «Зроби так, щоб я явно підтвердив ключові рішення».

Інакше кажучи, Claude має не просто видати готову спеку, а змусити користувача пройтися по критичних точках і підтвердити або скоригувати їх. Це може стосуватися, наприклад:

• вибору основної метрики успіху;
• припущень про цільову аудиторію;
• обраної архітектури рішення;
• компромісів між швидкістю й якістю.

Такий підхід перетворює AI на інструмент, який не відбирає в людини мислення, а навпаки — структурує його й підштовхує до усвідомлених рішень. У результаті спека стає не просто «довгим промптом», а продуманим документом, який справді відображає цілі, контекст і обмеження проєкту.

«Сучасна інженерія»: як виглядає зріла робота з Claude на першому шарі

Коли всі три елементи першого шару складаються разом, формується те, що Марчезе називає «modern engineering» — сучасною інженерією роботи з AI. Вона базується не на магічних формулюваннях промптів, а на дисципліні побудови специфікацій.

У зрілому вигляді цей процес виглядає так. Спочатку користувач разом із Claude через інтерв’ю виявляє справжню ціль проєкту й рішення, які мають бути ухвалені на основі результату. Потім задача розбивається на низку невеликих, чітко окреслених спек із проміжними контрольними точками, а модель свідомо «зміщують» у бік дрібних, відокремлених модулів роботи. Нарешті, кожна спека формулюється максимально точно, а ключові рішення всередині неї проходять явне підтвердження людиною.

На цьому етапі Claude ще нічого не «будує» — він допомагає створити карту майбутньої роботи, яка мінімізує ризики помилок на кшталт «піти пішки до автомийки». Модель отримує не розмитий запит, а структурований опис цілей, контексту й кроків, у межах якого її статистичні здібності можуть розкритися максимально безпечно й корисно.

Наступні шари методу Карпаті — верифікація результатів і побудова середовища, де ці процеси живуть постійно, — розширюють цю базу. Але саме перший шар, шар спеки, визначає, чи буде AI працювати як інструмент для реалізації людських цілей, чи як генератор переконливих, але потенційно хибних відповідей.

Висновок: AI не вгадає вашу ціль — її треба зафіксувати

Приклад із автомийкою показує, що навіть найсучасніші моделі можуть блискуче оперувати фактами й водночас провалюватися в елементарних життєвих ситуаціях. Причина не в «дурості» AI, а в тому, що він працює з поверхневим формулюванням задачі, а не з глибинною ціллю.

Метод Карпаті, у викладі Остіна Марчезе, пропонує просту, але вимогливу відповідь: перестати покладатися на високорівневі плани й почати будувати детальні спеки, які явно кодують людське розуміння цілей, контексту й обмежень. Для цього варто використовувати Claude не лише як виконавця, а як інтерв’юера й співавтора специфікацій, працювати в agile-ритмі невеликих кроків і змушувати себе явно підтверджувати ключові рішення.

У такій моделі AI перестає бути «чорною скринькою», якій кидають усе підряд у надії на диво. Він стає частиною дисциплінованого інженерного процесу, де головна цінність — не чарівний промпт, а якісно сформульована спека.

Джерело

Stop Prompting Claude. Use Karpathy’s Method Instead. — Austin Marchese

Агентні системи штучного інтелекту сьогодні легко вразити на демо, але значно важче змусити їх стабільно працювати в реальних продуктах. Канал IBM Technology розбирає, чому масштабування таких систем різко підвищує вартість, затримки та ризик збоїв — і чому це насамперед проблема архітектури, а не «слабкого» моделю.

Агент, який працює в демо, і агент, який має жити в продакшені — це різні істоти

Сучасні агентні системи зазвичай будуються навколо простого циклу:

• Планування — розбиття задачі на кроки
• Виконання — виклики інструментів, API, сервісів
• Пам’ять — збереження релевантного контексту
• Рефлексія — оцінка дій, корекція стратегії

Для вузьких задач це працює напрочуд добре: мало рішень, обмежений контекст, швидке завершення. Логічний наступний крок — «просто додати ще можливостей»: більше інструментів, більше доменів, ширші повноваження агента.

Саме тут починаються проблеми. Цикл агента формально не змінюється, але вартість кожної ітерації різко зростає:

• Планування займає більше часу, бо зростає кількість варіантів дій
• Виконання ускладнюється: потрібно обирати між більшою кількістю інструментів
• Пам’ять роздувається, у кожен крок передається більше контексту
• Рефлексія стає дорожчою і менш надійною — корисні сигнали губляться в «шумі»

У результаті латентність і вартість зростають не лінійно. Кожне рішення вимагає більше токенів, більше міркувань і обережнішого вибору дій. Додавання функцій не просто збільшує обсяг роботи — воно множить складність навіть для простих сценаріїв.

Ключовий наслідок: масштабування агентних систем підвищує вартість одного рішення і, зрештою, вартість одного успішного результату.

Коли маленька помилка отруює всю систему

Зі зростанням складності виникає ще одна, менш очевидна, але значно небезпечніша проблема: помилки перестають бути локальними — вони поширюються в часі.

Показовий приклад — агент-помічник з подорожей. Користувач просить: «Забронюй мені поїздку до Вашингтона». Система інтерпретує це як Вашингтон, округ Колумбія, хоча йшлося про штат Вашингтон. Далі:

• на основі цієї інтерпретації агент будує план
• викликає інструменти для пошуку рейсів, готелів, транспорту
• записує усі ці кроки в пам’ять як «успішно виконані»

Формально все відпрацювало «правильно» — але на хибному припущенні. Помилка на вході:

• визначила весь план
• вплинула на всі наступні дії
• була закріплена в пам’яті як частина історії взаємодії

У класичних системах помилка часто обмежена одним запитом. В агентних — вона розтягується в часі, отруюючи ланцюжок рішень. І чим більш автономно працює агент, тим менше природних «чекпоінтів», де людина могла б вчасно втрутитися.

Тобто зі зростанням масштабу агенти:

• приймають більше рішень в умовах невизначеності, а не менше
• мають більше можливостей поширити помилку через план, пам’ять і наступні дії

Проблема не в моделі, а в тому, хто за що відповідає

Інтуїтивне рішення — «зробити одного дуже розумного агента, який уміє все» — погано масштабується. Коли один агент:

• приймає всі рішення
• тримає всю пам’ять
• відповідає за всі домени

то зі зростанням обсягу задач:

• контекст стає зашумленим
• стан системи важко контролювати
• збої легко каскадуються
• вартість одного завдання постійно зростає

Це не обмеження моделі як такої, а наслідок централізації відповідальності. Ситуація нагадує компанію, де всі рішення — від інженерії до підтримки — проходять через одну людину. Зі зростанням бізнесу:

• кожне рішення вимагає більше контексту
• доводиться постійно перемикатися між доменами
• навіть дрібні питання вирішуються все довше

В агентних системах так само: коли відповідальність зосереджена в одному місці, вузьким місцем стає вартість прийняття кожного окремого рішення.

Отже, масштабування агентів — це насамперед задача системного дизайну, а не «гонка за найпотужнішою моделлю».

Мультиагентні системи: не модний тренд, а вимушена архітектура

Щоб вийти з пастки «всезнаючого агента», систему доводиться декомпозувати на кілька компонентів із чітко обмеженою відповідальністю. Кожен компонент:

• працює з меншим контекстом
• приймає менше рішень
• має вужчу сферу дії

У сукупності це дає:

• дешевші й швидші окремі рішення
• локалізацію складності
• обмеження поширення збоїв

Так природно виникають мультиагентні системи — як наслідок правильного масштабування, а не як самоціль.

Але разом із цим з’являється новий клас проблем: координація між агентами. Потрібно вирішити, як вони:

• ділять роботу
• обмінюються результатами
• управляють залежностями

Тут постає ключове архітектурне питання: де розміщувати нові можливості?

Горизонтальне vs вертикальне масштабування можливостей

Є дві основні стратегії:

1. Горизонтальне масштабування
   Додаються нові агенти з окремими зонами відповідальності. Плюси:
2. легше повторно використовувати можливості
3. чіткіші межі відповідальності

Мінус: координація стає вузьким місцем, а накладні витрати на комунікацію швидко ростуть.

1. Вертикальне масштабування
   Існуючі агенти «обростають» новими інструментами або підагентами. Плюси:
2. менше координаційних кроків
3. менше міжагентних залежностей

Мінус: зростає складність і латентність усередині окремих агентів.

На практиці це зводиться до питання: винести можливість в окремий агент чи вбудувати в наявний?

Приклад: дослідницький асистент

Уявімо систему дослідницького асистента з такою структурою:

• центральний координатор
• агент для пошуку документів
• агент для уточнення запитів
• агент для синтезу результатів

Як додати фактчекінг?

• Логічно зробити окремого агента, який перевіряє вихідні дані по всій системі.
  Це:
• окрема, багаторазово використовувана можливість
• зі своїми правилами й політиками
• корисна в різних точках пайплайну

Винос у окремий агент зберігає чистоту відповідальностей, але додає ще один крок координації.

А як додати ранжування та фільтрацію знайдених документів?

• Це тісно пов’язано з самим процесом пошуку та залежить від спільного контексту кроків.
  Тут логічніше вбудувати можливість у наявного агента пошуку, а не створювати нового. Інакше координація стане надмірною, а процес прийняття рішення — фрагментованим.

Звідси випливає практичне правило:

• Виносити в окремих агентів — можливості, які:
• повторно використовуються
• відносно незалежні

• мають власну політику й логіку

• Вбудовувати в існуючих агентів — можливості, які:

• тісно пов’язані з поточним процесом
• сильно залежать від локального контексту
• втрачають сенс при відриві від основного пайплайну

Системи, які реально масштабуються, — це ті, де свідомо обирають, де саме накопичується складність: у координації, в окремих агентах чи в структурі, що їх поєднує.

Масштабування підсилює не лише інтелект, а й усі проблеми

На кожному етапі масштабування агентних систем:

• зростає вартість
• збільшується латентність
• помилки легше поширюються
• координація ускладнюється

Масштабування не просто підсилює можливості — воно підсилює все, що є в системі. Тому успішними стають не ті команди, які мають «найрозумніших агентів», а ті, хто:

• обмежує розмір окремих рішень
• свідомо контролює, що саме дозволено масштабувати
• проектує системи так, щоб інтелект накопичувався, а не руйнувався під власною вагою

Мета при побудові агентних AI-систем — створити архітектуру, яка не лише витримає власний успіх, а й зможе отримувати з нього користь.

Джерело

Building AI Agent Systems and Scaling Challenges in Agentic AI — IBM Technology

Ось один спосіб придивитися до впливу SpaceX напередодні її IPO цього тижня: компанія настільки змінила ставлення венчурної індустрії до довгострокових, капіталомістких космічних проєктів, що талановитий засновник без досвіду в космічній галузі може профінансувати компанію з будівництва космічних дата-центрів.

Orbital — нова фірма, що в травні вийшла з акселератора a16z Speedrun із посівним раундом у $5 млн, — стала черговою компанією, яка обіцяє виконувати AI-обчислення на орбіті, щойно Starship почне регулярні польоти. Серед інших інвесторів — Basis Set, Human Element, Wayfinder, Antler, Anti Fund, Ascent, Rubik, Zero Knowledge Ventures, LYVC, Feld Ventures, New Legacy, FNDR, UpHonest і Asterisk.

Засновник і CEO Orbital Ювін Пун раніше створив компанію електросамокатів Spin у 2017 році й уже за рік продав її Ford, приєднавшись до автогіганта. Коли він був готовий запускати нову компанію, в a16z Speedrun охоче погодилися його підтримати. Партнер фонду Ендрю Чен розповів TechCrunch, що Пун пропрацьовував кілька ідей, перш ніж зупинитися на космічних дата-центрах.

Сама ідея вже знайома. Попит на обчислювальні ресурси для ШІ ненаситний, а розгортання потужностей на Землі відбувається повільно. Чому б не винести це в космос, де безмежна сонячна енергія й менше екологічних обмежень? Головна проблема — жорстка економіка запусків на орбіту, яка поки що робить бізнес-модель нежиттєздатною.

Як і багато конкурентів, Orbital робить ставку на те, що SpaceX відпрацює свою ракету Starship і запропонує її комерційним клієнтам. «Ми вийдемо на повний масштаб, коли Starship стане доступною», — пояснює Пун. Поточна ціна запусків Falcon 9, нинішнього флагмана SpaceX, «робить це економічно нереалістичним».

Поки що Пун і його команда — близько десятка людей у Лос-Анджелесі з досвідом роботи в Amazon LEO, SpaceX і Northrop Grumman — готуються до демонстраційного польоту. У його межах Orbital відправить чип Nvidia Blackwell на супутнику-партнері, щоб протестувати власні технології радіаційного захисту та терморегулювання. У 2028 році компанія сподівається запустити свій перший космічний апарат для обробки даних із GPU Nvidia Space-1 класу Vera Rubin.

На цьому етапі Orbital планує виконувати покрокову інференцію — обчислювальні завдання, які дозволять генерувати виручку з кожного запущеного супутника. Це подібний шлях до конкурента Starcloud, який уже має GPU на орбіті та планує запустити ще кілька, щоб заробляти до того, як Starship дозволить розгорнути повну сузірʼя.

Мета Orbital — вивести на орбіту 10 000 супутників, які забезпечать розподілену обчислювальну потужність на рівні гігавата, при цьому кожен апарат має генерувати 100 кВт. Для порівняння: Ілон Маск заявляв, що AI-супутники SpaceX зможуть видавати до 150 кВт, а Starcloud розраховує розгорнути ще більші апарати на 200 кВт для роботи чипів.

Деякі компанії не хочуть чекати Starship. Cowboy Space Company, ще один стартап космічних дата-центрів, що також має підтримку a16z, нещодавно вирішив самостійно будувати ракети. А космічна компанія Джеффа Безоса Blue Origin оголосила плани виводити дата-центри в космос за допомогою своєї ракети New Glenn.

Пун упевнений, що широта попиту на ШІ дозволить успішно працювати багатьом гравцям. «Є так багато різних напрямів, які компанії в нашій сфері можуть обрати», — сказав він TechCrunch, перелічивши серед варіантів різні типи AI-навантажень, конструкцій і концепцій того, як саме має виглядати космічний дата-центр.

Чен вважає, що досвід Пуна в масштабуванні бізнесу, який розгорнув 250 000 самокатів у 100 містах, доводить його здатність впоратися зі складним завданням побудови аерокосмічної компанії. У довгостроковій перспективі на такий проєкт може піти десятиліття та $5 млрд і більше, але, за словами Чена, венчурні фонди стають більш комфортно почуватися з такими горизонтами.

«Подібна ідея звучала б божевільно 10 років тому, коли ми всі робили мобільні додатки, — каже він. — Запустити таке в 2026-му означає скористатися всією енергією та ентузіазмом, які зараз є на ринку капіталу».

Пун прийшов до ідеї космічних дата-центрів обхідним шляхом. Після виходу з Ford він просто заради цікавості купив GPU Nvidia A100, розмістив його в дата-центрі в Санта-Кларі й почав надавати доступ до моделей з відкритими вагами. Власний досвід переконав його в цінності надання обчислювальних потужностей в епоху ШІ.

Тепер йому залишилося тільки вивести на орбіту пару тисяч GPU.

Джерело

TechCrunch

Європейський стартап з «vibe‑coding» Lovable повідомив TechCrunch, що перевищив позначку у $500 млн річної виручки (annualized revenue run rate).

Востаннє Lovable розкривала показники в лютому, коли компанія заявляла про подолання рівня $400 млн. У серпні 2024 року в Lovable прогнозували, що зможуть вийти на $1 млрд річної виручки протягом 12 місяців. Хоча компанія, ймовірно, не подвоїть цю цифру до літа, її зростання все одно виглядає вражаючим: стартап, заснований наприкінці 2023 року, ще навіть не відсвяткував третю річницю.

Компанія також стверджує, що на її платформі було створено понад 50 млн проєктів, а поточні темпи використання сягнули одного мільйона нових проєктів на тиждень. Згідно з опитуванням, результати якого Lovable публікує в корпоративному блозі, більшість користувачів не мають технічної освіти, але все активніше створюють програмні продукти, які планують монетизувати або використовувати у власному бізнесі.

За даними компанії, її користувачі — це засновники бізнесів, дизайнери та фахівці з продажу, які будують вебсайти й інтернет‑крамниці, а також внутрішні інструменти на кшталт CRM‑систем, рішень для управління запасами та HR‑платформ.

Цей перелік багато про що говорить. AI‑платформи для «vibe‑coding» уже сприймаються як загроза для класичного SaaS‑ПЗ: навіщо купувати дорогі річні підписки, якщо можна «навайбити» потрібний софт самостійно? Опитування Lovable дає певні підстави вважати, що це вже відбувається.

Однак Lovable і більшість побудованих на ній проєктів ще надто молоді, щоб відповісти на головне запитання щодо «vibe‑coded» ПЗ: чи виявиться такий підхід довгоживучим? Проблема зазвичай не в початковому створенні продукту, а в його довгостроковій підтримці та розвитку.

Джерело

TechCrunch

На тлі того, як стартапи Harvey та Legora витрачають десятки мільйонів доларів інвестицій, юридичні інструменти стали одним із найшвидше зростаючих і найгарячіших напрямів серед AI‑стартапів. Однак попри фокус цих рішень на юридичній практиці для зовнішніх клієнтів, частина ринку досі залишається недослуженою.

Стартап Sandstone, який у вівторок оголосив про залучення $30 млн інвестицій у раунді серії A, націлений саме на цей менш помітний сегмент — внутрішні юридичні команди компаній, що працюють із заплутаним набором завдань і розрізнених систем.

Раунд серії A очолив фонд Lightspeed Venture Partners, до нього також долучилися наявні інвестори Mantis VC, SV Angel, Operator Partners, Kearny Jackson, Daybreak Ventures, Litquidity Ventures та інші. Нове фінансування надійшло лише через шість місяців після посівного раунду обсягом $10 млн у січні, який очолювала Sequoia.

Як пояснюють засновники, початковою аудиторією Sandstone стануть юридичні відділи малих і середніх компаній.

“Вони зранку відкривають ноутбук і бачать весь обсяг роботи, що надійшла через різні канали — повідомлення в Slack, електронні листи, Jira”, — розповів TechCrunch співзасновник і операційний директор Sandstone Джаррид Стрідом. — “AI допомагає їм правильно маршрутизувати й сортувати ці запити, а потім на нашій платформі можна будувати кастомні робочі процеси для виконання завдань — від підготовки документів і ревʼю до надання юридичного аналізу”.

Результат мало схожий на системи юридичного міркування на кшталт Harvey чи Legora. Натомість Sandstone фокусується на керуванні взаємодіями та автоматизації робочих процесів, налаштованих під специфічні потреби внутрішніх юрдепартаментів. На думку Стрідама, саме цей фокус дозволяє Sandstone давати відчутну користь там, де більш загальні AI‑рішення часто не спрацьовують.

“Одне з переконань Lightspeed полягає в тому, що вони вірять у високоспеціалізований вертикальний AI”, — каже Стрідом. — “Тому що потрібне дуже детальне розуміння робочих процесів, аби по‑справжньому точно визначити, як саме AI може допомогти”.

Джерело

TechCrunch

Пошук нових застосунків в App Store від Apple менше залежатиме від перегляду топ-чартів чи добірок від редакторів. Цього тижня Apple оголосила про низку нових інструментів відкриття контенту, які персоналізуватимуть рекомендації застосунків залежно від інтересів і поведінки користувачів, відкриваючи для розробників нові можливості бути поміченими.

На конференції розробників WWDC Apple представила в App Store функцію Personalized Collections — персоналізовані добірки, які показуватимуть рекомендації, підібрані під конкретного користувача. У цих добірках також з’являться нові «App Notes» — пояснення, чому саме ці застосунки пропонуються вам. Починаючи з цього тижня, нові персональні поради будуть з’являтися в різних розділах App Store, зокрема на вкладках Apps або Games, а також на вкладці Search.

Рекомендації змінюватимуться з часом залежно від того, які застосунки користувач завантажує та як ними користується.

Спочатку функція буде доступною англійською мовою в США, а згодом, за словами Apple, розшириться на інші регіони та мови. Вона доповнює цілий набір нових інструментів, покликаних допомогти розробникам краще рекламувати свої продукти потенційним клієнтам і мотивувати користувачів повертатися до своїх застосунків та ігор.

Оновлення відображає зрілість екосистеми App Store, де розміщення в розділі «Вибір редакції» чи статус «App of the Week» уже не гарантують зростання аудиторії. На тлі посилення конкуренції за увагу користувачів новий набір інструментів має допомогти повторно залучати існуючих клієнтів, просувати спеціальні пропозиції та комбінувати сервіси в новий спосіб.

Наприклад, розробники тепер зможуть використовувати багаті зображення та відео в шапці сторінки застосунку й у результатах пошуку, щоб підкреслити новий контент або сезонні пропозиції. Це може спонукати наявних користувачів повернутися до застосунку, щоб подивитися, що змінилося. Також вони зможуть впорядковувати свої маркетингові матеріали в новій бібліотеці Asset Library, де зберігатимуться постійно використовувані ресурси для in-app подій, розпродажів та промо-акцій. Окремо розробники отримають можливість показувати спеціальні пропозиції й залучати гравців через застосунок Apple Games.

Apple також дозволить створювати App Bundles для розробників, які працюють за підписною моделлю. Це дасть їм змогу об’єднуватися з іншими розробниками та пропонувати пакети застосунків за підпискою за нижчою ціною, ніж у разі оформлення кожної підписки окремо.

У межах нової системи розробники також зможуть продавати підписки більшим групам і організаціям, завдяки новим опціям створення багатокористувацьких сценаріїв in-app покупок.

Джерело

TechCrunch

Вересень і так виглядав надзвичайно насиченим місяцем для великих ігор, адже багато великих розробників і видавців намагаються уникати дати релізу Grand Theft Auto 6, запланованої на 19 листопада. Під час останньої презентації Nintendo Direct компанія ще більше посилила конкуренцію, підтвердивши, що Fire Emblem: Fortune’s Weave вийде на Switch 2 вже 17 вересня.

Це перша нова частина серії з часів Fire Emblem Engage 2023 року. Nintendo анонсувала останню на сьогодні гру франшизи минулого вересня.

Джерело

Engadget

Orbitals, ексклюзивна гра для Switch 2 в аніме-стилі від видавця Kepler Interactive, вийде 3 вересня. Про це Nintendo оголосила сьогодні під час своєї літньої презентації Direct. Перший повноцінний погляд на гру показали ще в лютому, коли вона завершувала показ партнерського Direct. Тоді Nintendo обіцяла реліз Orbitals «влітку», і зараз виглядає, що гра дотримається цього графіка.

Якщо Orbitals ще не потрапила у ваше поле зору, її найкраще описати як кооперативну пригодницьку головоломку для двох гравців. Ви разом з другом або членом родини граєте за пару міжгалактичних дослідників, які мають врятувати свою домівку від космічної бурі, що наближається. Візуальний стиль у дусі аніме 1990-х одразу впадає в око, але гра також виглядає як цікава варіація на кшталт It Takes Two та Split Fiction.

Orbitals підтримуватиме локальний і онлайн-кооператив, а завдяки функції GameShare на Switch 2 лише одному гравцю потрібно буде придбати гру, щоб у неї могли грати двоє. Попереднє замовлення Orbitals уже доступне в Nintendo eShop.

Джерело

Engadget

Pokémon Pokopia отримає велику порцію нового контенту, починаючи з безплатного оновлення, яке додасть підводну механіку. Вона стане доступною завдяки новому прийому дайвінгу, який головному герою Дітто, найімовірніше, подарує водний покемон. Безплатне оновлення вийде вже в серпні.

Це означає, що гравці зможуть продовжувати свої будівельні проєкти глибоко в океані, що справді додасть грі нового виміру. Особливо це актуально для більш водних локацій у Pokémon Pokopia.

Nintendo також анонсувала Expansion Pass — подібно до того, як це було з Mario Kart 8. Він відкриє доступ до трьох майбутніх DLC-наборів, хоча їх можна буде купувати й окремо. Деталей щодо всього контенту поки немає, але вже відомо, що з’явиться нове підводне місто з новими меблями, вбраннями і, звісно, новими покемонами для спілкування.

Перше DLC з підводним містом вийде в серпні, ймовірно разом з оновленням із дайвінгом. Другий пакунок очікується пізніше цього року й міститиме «додаткові нові можливості». Третє платне оновлення заплановане на 2027 рік і додасть ще одне місто.

Джерело

Engadget

Уперше Apple дозволить розробникам об’єднуватися між собою та пропонувати передплатні набори в App Store, які надаватимуть доступ до кількох додатків за нижчою ціною, ніж окрема підписка на кожен з них.

На заході WWDC 2026 виробник iPhone оголосив про розширення можливостей функції App Bundles, яка раніше дозволяла розробнику з кількома додатками продавати їх у вигляді одного пакета.

Тепер, за словами Apple, розробники зможуть об’єднуватися, щоб запропонувати користувачам «більше за менші гроші». Замість того щоб формувати набори лише з власних додатків, розробники можуть співпрацювати та створювати спільні пакети, які коштуватимуть дешевше, ніж сума окремих підписок.

Нова модель пакетів запозичує стратегію, що стала поширеною у сфері стримінгу та медіа, де компанії на кшталт HBO і Disney об’єднують свої сервіси, щоб підвищити їхню цінність в очах користувачів і краще утримувати аудиторію.

Такі набори можуть бути вигідними й для розробників з перетинанням аудиторій, але без прямої конкуренції між собою. Наприклад, можна уявити креативний пакет, що включає камеру, інструменти для редагування фото та відео, а також додаток для публікації контенту в соцмережах.

Подібним чином розробники продуктивних додатків можуть об’єднуватися, щоб закрити прогалини у функціональності власних продуктів. Користувачі зможуть купувати пакет, у який, наприклад, входять список справ від одного розробника та календар від іншого.

Apple також зазначає, що розробники зможуть створювати так звані Suites — пакети підписок, які не будуть доступні для купівлі окремо.

Джерело

TechCrunch

Razer розширює лінійку рішень для цифрових креаторів, представивши свій перший мікрофон для стримінгу та подкастів із підтримкою XLR — Seiren V3 Pro. Завдяки вбудованому цифровому сигнальному процесору (DSP) та низці інших зручностей компанія позиціонує новинку як мікрофон, що підійде і новачкам, і більш досвідченим авторам.

Головна відмінність Seiren V3 Pro від його попередника Razer Seiren V3 Chroma — наявність аналогового роз’єма XLR поруч із подвійним USB-C. XLR є стандартом для професійних мікрофонів, але такі пристрої потребують підключення через аудіоінтерфейс або мікшер перед з’єднанням із комп’ютером. Через це початківці, які роблять перші кроки у стримінгу чи записі аудіо, часто обирають USB-мікрофони, що працюють за принципом plug-and-play з будь-якою сучасною ОС. Razer додала обидва варіанти підключення в Seiren V3 Pro, дозволяючи новачкам стартувати через USB, а згодом докупити обладнання для роботи по XLR.

Цей фокус на зручності простежується і в інших елементах продукту. Razer окремо підкреслює роль вбудованого DSP — ще одного інструмента, дружнього до новачків. Одне з найскладніших завдань при використанні професійних мікрофонів — правильна еквалізація звучання та контроль акустики приміщення. Багато початківців купують якісний мікрофон, очікуючи відмінного звучання «з коробки», але швидко з’ясовують, що без технічних знань результат мало відрізняється від мікрофона у вебкамері.

Razer стверджує, що вбудований DSP, який працює при підключенні Seiren V3 Pro через USB-C, містить AI-фільтр шуму, а також компресор, лімітер і експандер. Це має зняти потребу у новачків розбиратися з десятками незрозумілих регуляторів і кнопок. Додатково вбудовані шок-абсорбер (антивібраційне кріплення) та поп-фільтр покликані вирішити ще дві типові проблеми при записі.

Корпус Razer Seiren V3 Pro виконаний у вигляді моноблока з регулятором чутливості (gain) і кнопкою вимкнення звуку. У комплекті є кронштейн-«рука» з регулюванням положення й демпфуванням вібрацій. Усередині використовується 30-мм капсула з кардіоїдною характеристикою спрямованості та діапазоном частот від 50 Гц до 16 кГц. Це помітно вужчий діапазон, ніж у студійних мікрофонів для запису в кабіні, але він відповідає рівню конкуруючих стримерських моделей, таких як Shure MV7+, а також сценічних мікрофонів на кшталт класичного Shure SM58.

Як і очікується, Seiren V3 Pro підтримує програмне забезпечення Razer Synapse, яке забезпечує роботу 32-бітного float-запису та керування вбудованим RGB-підсвічуванням. Орієнтовна роздрібна ціна становить $249,99.

Джерело

Engadget

Nintendo офіційно анонсувала ремейк The Legend of Zelda: Ocarina of Time, поклавши край місяцям чуток і спекуляцій. Компанія показала короткий трейлер під час сьогоднішньої трансляції Nintendo Direct, і за першим враженням це повноцінний ремейк із суттєво оновленою графікою. Реліз заплановано на кінець цього року для Switch 2, деталі обіцяють розкрити пізніше.

Поки що залишається багато запитань, зокрема щодо ціни та наявності нового контенту. Невідомо й те, чи готується ремейк Majora’s Mask. Утім, приємно, що Nintendo так масштабно відзначає день народження франшизи, адже всі розуміють: на нову повноцінну 3D-Zelda доведеться чекати ще кілька років. Між виходами Breath of the Wild та Tears of the Kingdom минуло понад шість років, хоча обидві гри працюють на одному рушії й використовують значну частину тієї самої мапи.

Це, звісно, не перший ремейк Ocarina of Time. Гру вже переробляли для 3DS, як і Majora’s Mask. Вона також виходила на Wii, Wii U та Switch через Virtual Console і сервіс підписки Nintendo Switch Online + Expansion Pack.

Джерело

Engadget