Прогноз щодо кінця електронних таблиць Генерація коду на основі ШІ означає, що все, що зараз моделюється у вигляді таблиці, краще моделюється в коді. Ви отримуєте всі переваги програмного забезпечення — бібліотеки, відкритий код, штучний інтелект, усю складність і виразність. Подумайте, що таке електронні таблиці насправді: це бізнес-логіка, застрягла в сітці. Моделі ціноутворення, фінансові прогнози, трекери запасів, маркетингова атрибуція — це по суті *програми*, які ми пишемо у найгіршому IDE. Немає контролю версій, немає тестування, немає модульності. Просто крихка мережа посилань на клітинки, яка розривається, коли хтось вставляє рядок. Єдина причина, чому перемогли електронні таблиці, — це надто високий бар'єр для написання справжнього програмного забезпечення. Фінансовий аналітик міг би вивчити =VLOOKUP за один день, але не міг вивчити Python за місяць. Генерація коду ШІ повністю перевертає цю ситуацію. Тепер той самий аналітик описує, що йому потрібно, простою англійською, і отримує реальне застосування — з базою даних, інтерфейсом, обробкою помилок і всім усім. Маргінальна спроба перейти від «електронної таблиці» до «програмного забезпечення» просто зникла майже до нуля. Це величезне відкриття. У світі є ~1 мільярд користувачів електронних таблиць. Більшість із них створюють несправне програмне забезпечення, навіть не усвідомлюючи цього. Коли навіть 10% цих випадків мігрують у реальний код, виникає вибух нових мікрозастосунків, які зовсім не схожі на традиційне програмне забезпечення. Внутрішні інструменти, які раніше працювали у спільній Google Sheet, тепер стають реальними продуктами. «Тіньова ІТ-таблиця», яка керує половиною операцій компанії, нарешті отримує належну інфраструктуру. Цікавий ефект другого порядку: електронна таблиця була великим вирівнювачем, який дозволяв нетехнічним людям створювати речі. AI-генерація коду — це *наступний* великий еквалайзер, але стеля у 100 разів вища. Ми ось-ось побачимо, що станеться, коли мільярд працівників знань зможе створити справжнє програмне забезпечення.
Читаючи відповіді — багато хто ненавидить це передбачення! Багато хто не може уявити програмування логіки/змінних/вхідних даних без парадигми таблиці Мій основний контраргумент: - багато скарг надходить від людей, навчених користуватися клавішними скороченнями у Windows Excel на Thinkpad у їхні славні банківські часи, і вони клянуться, що ніколи не переключаться на щось інше. Пізній користувач — звичайні фінансові брати. Незабаром буде порушено Мої реальні контраргументи: - саме програмування змінювало свій UX багато, багато разів. Перфокарти, введення у файли, IDE і тепер LLM-кодування. Електронні таблиці — не єдиний спосіб кодування бізнес-логіки — існують кращі способи, одночасно поєднуючи всю потужність програмного забезпечення - мережевий UX може залишатися в якійсь формі, але це радше відображення. Так само, як ви програмуєте в Codex/Claude, але при цьому відкриваєте веб-сторінку. Або, можливо, у вас буде сітка як база даних, але ви будете створювати додатки зверху, але все одно хочете інтерфейс запитів для даних - LLM роблять перехід між логікою в коді та логікою в електронних таблицях взаємозамінним. Тож, можливо, ви редагуєте в сітці, але потім натиснете «розгорнути», і це створить вебдодаток у хмарі. І так само, як у нас є VLOOKUP(), вони будуть LLM(), які можуть кодувати логіку ШІ - Кожен, хто працює з програмним забезпеченням, знає, що воно безмежно краще, виразніше і потужніше. Генерація коду на основі ШІ — це благословення для всіх нетехнічних майстрів Excel, які тепер можуть підняти свою роботу на новий рівень
337