ШІ побудує твою систему аналітики за два дні. Ось що це число реально описує.

ШІ може генерувати сайти, застосунки, і бізнес-системи швидше, ніж будь-коли. Але швидкість генерації, це не те саме, що швидкість побудови того, на що бізнес реально може покластись.

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

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

Розрив між демо і реальною річчю розібраний глибоко у Claude побудує сайт, але не розуміння. Цей матеріал йде туди, куди той не заходив: у те, що реально потрібно, щоб побудувати справжню ШІ-систему аналітики, ту саму, що постійно з'являється в цих курс-пітчах.

Проблема ніколи не була в тому, що ШІ не може будувати вражаючі речі. Проблема в тому, що "побудовано" стало одним з найзловживаніших слів у розмові про ШІ. Дводенне демо може бути повністю реальним. Питання в тому, що ці два дні реально виробили.

"Побудовано" стало одним з найзловживаніших слів у розмові про ШІ. Дводенне демо може бути реальним. Питання в тому, що ці два дні реально виробили.

ЧИСЛО ДВА ДНІ

Число "два дні"

"Я побудував ШІ-систему аналітики за два дні" може означати кілька дуже різних речей. Згенерував дашборд. Підключив API. Створив базу даних. Написав краулер. Побудував робочий прототип, що тягне дані з одного джерела в приємний інтерфейс. Все це можливо, і частина цього по-справжньому чудова.

Але система аналітики, на яку компанія реально може покластись, це дещо інше. Різниця не в тому, чи здатний ШІ. Вона в тому, що відбувається після того, як перша версія починає працювати. У софту два дуже різні моменти: момент, коли щось працює, і значно довший період, у якому це має продовжувати працювати, означати правильну річ, пережити реальність, і заслуговувати на довіру. Це не одна й та сама віха.

АНАЛІТИКА НЕ ПРОМПТ

Система аналітики, це не промпт

Візьмемо систему, що постійно з'являється в ШІ-демонстраціях: компанія, що працює в десяти країнах, хоче визначити конкурентів, відстежувати ціни і позиціонування, порівнювати видимість у пошуку по ринках, і генерувати рекомендації, можливо навіть діяти за деякими з них автоматично.

Що реально вимагає "проаналізуй наших конкурентів"

Попроси ШІ побудувати це, точно те архітектурне питання, що стоїть під будь-якою реальною системою, і він допоможе майже з кожним шаром. Це по-справжньому вражаюча частина. Але зауваж: "ШІ-аналіз", це лише один компонент. Архітектура навколо нього все ще існує, і саме там живе більшість реальних рішень.

ЩО ЗАРАХОВУЄТЬСЯ ХТО ВИРІШУЄ

Що зараховується, і хто вирішує

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

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

НЕ ВСІ ДАНІ ДАНІ

Не всі дані, це дані

Частина інформації виміряна. Частина оцінена. Частина виведена, і це не взаємозамінне. Публічно повідомлена метрика платформи, це факт. Оцінка трафіку від стороннього сервісу, це оцінка. Здогадка ШІ про конверсію конкурента, без доступу до первинних даних, це висновок, одягнений в одяг числа. Все це може сидіти в одному гарному дашборді. Це не робить все однаково правдивим.

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

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

РОЗВЯЗАННЯ СУТНОСТЕЙ

Нудна проблема, що ламає все

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

Звіт може згенеруватись ідеально. Висновок під ним може бути повністю невірним. Саме тому складна аналітика ніколи не буває просто "дай ШІ сайти і спитай, що він думає".

НЕМАЄ ЄДИНОГО ШІ

Немає єдиного "ШІ"

"Я попросив ШІ проаналізувати ринок" саме по собі мало що каже. Яку модель. З яким контекстом, якими інструментами, яким доступом до даних, яким краулером, якою пошуковою інфраструктурою, якими інструкціями, якою валідацією. Чи перевірили результат незалежно. Той самий розрив між твердженням і реальністю проявляється і в твердженнях про здатності ШІ загалом, не лише в аналітиці. Різні моделі й інструменти виробляють драматично різні процеси: один з живим доступом до вебу, інший, що працює переважно з наданою інформацією, один сильніший у коді, інший краще підходить для конкретного завдання міркування.

"Я попросив ШІ", це не методологія. Це опис взаємодії з інтерфейсом. Методологія починається з усього, що навколо.

ШІ КЕРУЄ ШІ

ШІ тепер може керувати ШІ

Тут стає цікавіше. Проста модель людина→ШІ→результат вже замінюється чимось більш багатошаровим.

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

Це по-справжньому потужно, і це створює реальний парадокс.

Додавання більшої кількості ШІ не прибирає архітектуру. Воно робить архітектуру важливішою.

Комусь все ще потрібно вирішити, яке завдання реально стоїть, яка модель що робить, що вважається успіхом, що є помилкою, що можна прийняти автоматично, що потребує ще одного огляду, що можна змінити в продакшені, і коли всій системі варто відкотитись. Ніщо з цієї інженерії не зникло. Вона перемістилась на рівень вище. Людина все більше проєктує систему, що вирішує, як ШІ-системи працюють разом, а це зовсім інше майбутнє, ніж "ШІ замінює розробника".

ШІ В ДИЗАЙНІ

Ми використовуємо ШІ і в дизайні

Це не лише про софт. Ми використовуємо Astra разом з Blender, щоб генерувати і досліджувати архітектурні й інтер'єрні візуалізації, і результати цілком непогані. Для картинок у блог і невеликих проєктів ця технологія вже по-справжньому корисна, заощаджуючи реальний час і виробляючи ітерації, що раніше зайняли б значно більше ручної роботи.

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

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

КОД ПРАЦЮЄ НЕВІРНИЙ

Код, що працює, все ще може бути невірним

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

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

ШІ ТОРКАЄТЬСЯ ПРОДАКШЕНУ

У момент, коли ШІ торкається продакшену, все змінюється

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

Мета-опис, можливо. Ціна, це інше. Логіка чекауту, зовсім інше. Структура бази даних сидить в окремій категорії ризику. "ШІ все лагодить за тебе" звучить прекрасно в демо. У продакшені цікаве питання не в тому, чи може він щось полагодити. А в тому, чи готовий ти йому це дозволити, і за яких умов.

БУДУЄМО ВЛАСНУ SALESFORCE

Я іноді жартую, що ми будуємо власну Salesforce

Тут я можу використати власний проєкт, але лише якщо жарт зрозумілий правильно. Ми будуємо власний двигун продажів, значно менший і спеціалізованіший, ніж Salesforce, у розробці вже деякий час, побудований з розробниками, різними моделями, і з ШІ, глибоко залученим на всьому протязі. ШІ допомагає писати код, досліджувати рішення, налагоджувати, і міркувати через реалізацію. Він пришвидшує багато роботи.

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

Моделі коштують грошей. Токени коштують грошей. Інфраструктура коштує грошей. Час розробника, включно з часом, витраченим на читання ШІ-згенерованого коду, його тестування, виявлення, що воно невірне, і його переробку, все ще інженерний час. ШІ змінює економіку. Він її не скасовує.

СТВОРЕННЯ ДЕШЕВШЕ СКЛАДНІСТЬ

ШІ зробив створення дешевшим. Складність все ще дорога.

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

ШІ не прибрав складність. Він її перемістив.

ДЕМО ПРОТИ СИСТЕМИ

Різниця між демо і системою

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

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

ЧОМУ ДЕМО ПЕРЕКОНЛИВЕ

Чому демо настільки переконливе

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

ШІ згенерував базу даних. Значить я можу побудувати ERP. ШІ згенерував дашборд. Значить у мене є система аналітики. ШІ згенерував гарний рендер. Значить я замінив професійний дизайн-воркфлоу. ШІ згенерував застосунок. Значить я побудував продукт.

Технологія реальна. Стрибок в інтерпретації, ось де починається проблема.

Хто верифікує дані. Хто вирішує, чи вірна бізнес-логіка. Хто розуміє архітектуру через шість місяців. Хто помічає, що краулер перестав працювати. Хто відкочує автоматичну зміну, коли вона невірна. Жодне з цих питань не годиться для вражаючого демо. Вони все одно лишаються питаннями, що визначають, чи реально ця річ корисна.

"Побудовано за два дні" описує генерацію. Воно не описує володіння.

ВИКОРИСТОВУЙ ШІ АГРЕСИВНО

Використовуй ШІ агресивно. Довіряй йому обережно.

Ніщо з цього не аргумент, що ШІ лишиться там же, де зараз. Моделі покращаться, агенти стануть здатнішими, верифікація стане більш автоматизованою, і ШІ, ймовірно, візьме на себе ще більше воркфлоу розробки й дизайну, ніж вже взяв. Правильна відповідь не в тому, щоб вдавати інакше. Вона в розумінні того, що реально змінюється прямо зараз, сьогодні, не в тому, що може згодом стати правдою. По мірі того як системи стають автономнішими, комусь все ще потрібно визначити, що означає "вірно", і ця відповідальність може стати важливішою по мірі зростання автоматизації, не меншою.

Ми використовуємо ШІ щодня, для досліджень, письма, дизайну, роботи в Blender, налагодження, архітектури, аналітики, і все більше для оркестрації інших ШІ-систем. Він зробив нас значно здатнішими, і саме тому нам не потрібно вдавати, що це магія. ШІ може стиснути місяці в тижні, тижні в дні, дні в години, іноді в хвилини. Ця частина реальна. Але продакшн-системі байдуже, чи зайняла функція в розробника три години чи в моделі тридцять секунд. Вона має працювати. Дані мають означати те, що ти думаєш, вони означають. Архітектура має пережити зміну. Комусь потрібно розуміти, що відбувається, коли це падає.

ШІ змінив економіку створення софту. Він не змінив економіку помилок.

Реальне питання ніколи не було "чи може ШІ побудувати це за два дні". Воно в тому, "що конкретно ти маєш на увазі під побудовано".

Чи може ШІ реально побудувати робочу систему аналітики за два дні?

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

Чому обіцянки курсів на кшталт "побудуй CRM за три дні" поширюються так легко?

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

Що таке розв'язання сутностей і чому це важливо для конкурентного аналізу?

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

Чи прибирає використання кількох ШІ-моделей, що перевіряють роботу одна одної, потребу в архітектурі?

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

Якщо ШІ пише більшу частину коду, хто реально несе відповідальність за результат?

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