Технічний контекст
Я дивлюся на Cursor IDE не як на «розумний редактор», а як на тонкий шар білінгу поверх LLM API. І саме тому мене не дивує кейс, коли $20 підписки відлітають за ~6 годин активної роботи: у Cursor вартість агента — це не «запит», а сума вхідних/вихідних токенів, помножена на тариф конкретної моделі, плюс накладні витрати на оркестратор агента.
Зараз у Cursor гібридна модель: фіксована підписка та кредитний пул, оцінений у доларах і прив’язаний до цін провайдерів моделей. На Pro за $20 на місяць ви фактично отримуєте близько $20 агентських кредитів. Pro+ за $60 дає більше кредитів, Ultra за $200 — ще більше. Але ключовий момент не в цифрах, а в тому, що токени «дорогих» сценаріїв зростають нелінійно.
Що мені як архітектору кидається в очі: агентська сесія легко перетворюється на багатомільйонний контекст. Причина проста — агент не працює «по одному файлу». Він читає дерево проєкту, підхоплює логи, діффи, конфіги, часто робить кілька ітерацій планування/виконання. Якщо ви дебажите Terraform або AWS-інцидент, то в контекст потрапляють:
- кілька модулів IaC, змінні, locals, outputs;
- плани/стейти, шматки CloudTrail/CloudWatch, іноді JSON-політики;
- обговорення гіпотез і повторні прогони.
Додайте сюди перемикання на преміальну модель (або режими з великим контекстом/«max») — і одна «агентська розмова» починає коштувати як десятки звичайних запитів. Навіть спроба рятуватися автоселектором моделі або Composer не гарантує економії: автоселектор все одно може вибрати дорожчу модель, якщо вважає завдання складним, а Composer часто розширює контекст, щоб «тримати в голові» план робіт.
Окрема зона ризику — фонові агенти та інструменти на кшталт Bugbot, які можуть тарифікуватися окремо і ближче до «чистого API-споживання». З архітектурної точки зору це означає, що ваша IDE раптово стає постійно працюючим споживачем токенів, а не інтерактивним асистентом.
Вплив на бізнес та автоматизацію
У бізнесі мене цікавить не «як круто він пише код», а скільки коштує одна одиниця результату: закритий тікет, виправлений інцидент, готовий модуль Terraform, пройдений security review. На гібридній схемі Cursor ціна такої одиниці може плавати в рази. І це ламає звичну економіку розробки: ви можете планувати навантаження по людино-годинах, але не можете планувати токени без дисципліни та інструментів контролю.
Хто виграє від моделі Cursor? Команди, де агент використовується дозовано: короткі сесії, обмежений контекст, зрозумілі правила, які завдання віддають агенту, а які — звичайному автокомпліту. Програють ті, хто сприймає агент як «поставте на автопілот і нехай сам розрулить інфраструктуру». В IaC та хмарі автопілот часто перетворюється на «прочитай все, спробуй все, поясни все», тобто в рахунок на токени.
Я бачу тут пряму паралель з тим, як компанії провалюють впровадження ШІ: купують інструмент, але не купують процес. У моїй практиці в Nahornyi AI Lab стійкий ефект дає не вибір «Cursor vs Windsurf», а архітектура використання:
- Політики контексту: що агент має право читати/індексувати, а що заборонено (особливо в монорепозиторіях та з секретами).
- Ліміти та «стоп-крани»: денні/тижневі бюджети, алерти, заборона на дорогі моделі за замовчуванням.
- Класифікація завдань: генерація шаблонів і дрібні правки — одне, дебаг прод-інциденту — інше, міграція інфраструктури — третє.
- Спостережуваність (Observability): метрики токенів/вартості по репозиторіях, командах, типах завдань, щоб припиняти «невидимі» витоки.
На цьому тлі підхід Windsurf з фіксованою ціною за користувацький промпт виглядає психологічно комфортніше: фінансовий сюрприз менш імовірний. Але я не ідеалізую фікс-прайс: він часто означає приховані обмеження щодо якості моделі, глибини агентності або частоти. Для керівника розробки питання одне: де ви хочете платити — «явно за токени» чи «неявно обмеженнями».
Якщо ваша мета — ШІ автоматизація в розробці та DevOps, вам потрібен передбачуваний операційний контур: хто запускає агентів, як вимірюється вартість, які сценарії дозволені. Інакше вийде парадокс: AI-IDE економить час інженера, але збільшує непередбачувані операційні витрати, які важко пояснити CFO.
Стратегічне бачення та заглиблення
Мій прогноз простий: ринок AI-IDE піде у дві крайнощі. Перша — «compute-aligned» інструменти на кшталт Cursor, де ви платите близько до собівартості LLM і отримуєте максимум потужності, але зобов'язані управляти споживанням як хмарними ресурсами. Друга — «fixed-experience» продукти, де вам продають передбачуваність, але зі стелею щодо агентності та контексту.
З погляду AI-архітектури я б уже зараз ставився до агентських режимів як до маленького внутрішнього сервісу, а не функції редактора. У проєктах Nahornyi AI Lab я закладаю для таких інструментів ті самі практики, що і для хмари:
- пісочниці для ризикованих завдань (інциденти, IAM-політики, Terraform apply);
- розподіл ролей: «читач» vs «виконавець», щоб агент не перетворювався на неконтрольованого оператора;
- обов'язковий короткий контекст за замовчуванням і розширення контексту лише за запитом;
- пост-аналіз: які сесії були дорогими і чому (зазвичай причина — зайві файли, нескінченні ітерації або неправильна постановка задачі).
Найнеприємніша пастка — ілюзія, що перемикання моделі на «Auto» автоматично вирішить економіку. Auto іноді допомагає, але не лагодить головну причину перевитрат: погано обмежений контекст і відсутність бюджету на задачу. Коли агент «пережовує» лог-файли, плани Terraform і десятки модулів, економія на моделі дає відсотки, а не порядок.
Я віддаю перевагу чесному підходу: на складні інфраструктурні завдання або виділяється окремий бюджет (і це обґрунтовано ціною простою/помилки), або ми перебудовуємо процес так, щоб агент працював фрагментами і видавав артефакти, що перевіряються. Хайп закінчується там, де починається контроль вартості та відповідальності. Корисність — там, де результат повторюваний, вимірюваний і вписується в регламенти.
Якщо ви хочете зробити ШІ автоматизацію без сюрпризів у рахунках, я запрошую обговорити ваш сценарій: репозиторії, типи завдань, бюджет, вимоги безпеки. Напишіть мені — Vadym Nahornyi — і ми в Nahornyi AI Lab спроєктуємо впровадження штучного інтелекту в розробку так, щоб агент пришвидшував роботу, а не випалював ліміти.