# Jev – новий if/else, за який тепер платять токенами?

> Розбираємо Jev від TypeSafe AI: перша «System One» модель, яка повертає типізовані рішення замість тексту. Що це насправді, приклад на TypeScript, чесні бенчмарки і коли звичайний if/else усе ще виграє.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-09-24
- Оновлено: 2026-09-24
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/jev-ai-typesafe

---

**Коротка відповідь.** Jev – це нова модель від TypeSafe AI, яка не генерує текст взагалі. Ти даєш їй стан (текст або JSON) і типізовані запитання, а вона повертає рішення: вибір зі списку, оцінку за шкалою або ймовірність «так/ні» – з каліброваною впевненістю і за 70–500 мс. Фактично це «if/else на стероїдах» для випадків, коли умова написана природною мовою. Це не заміна LLM і тим паче не заміна бізнес-логіки – це окремий, вужчий інструмент. Розбираємось, коли він доречний, а коли це просто дорогий класифікатор.

## Новий if/else

Кожен із нас колись писав щось таке:

```ts
if (message.toLowerCase().includes('термінов')) {
  return 'high_priority';
}
```

І воно навіть працювало. Рівно до моменту, коли клієнт написав «та не горить, але бажано швидше», і твій `includes()` відправив його в чергу з пожежами. Або навпаки: «У МЕНЕ ВСЕ ЗЛАМАЛОСЬ І НІЧОГО НЕ ПРАЦЮЄ!!!» без жодного ключового слова спокійно осів у стандартній черзі на три дні.

П'ятнадцятого вересня 2026 року компанія TypeSafe AI [вийшла зі стелсу](https://typesafe.ai/blog/introducing-system-one-models-and-jev) з моделлю Jev і сміливою заявкою: спеціальна модель, яка нічого не пише, а лише приймає рішення. Запуск зібрав тред на ~1800 поінтів на [Hacker News](https://news.ycombinator.com/item?id=49767192), інтеграції з'явились у [Vercel AI SDK](https://vercel.com/kb/guide/typesafe-jev-and-ai-sdk) і [LangChain](https://www.langchain.com/blog/building-a-harness-with-jev), а компанію заснував Diogo Almeida – колишній дослідник OpenAI і один зі співавторів RLHF.

Іронія ситуації прекрасна: десятиліттями ми писали умови руками. Потім навчили величезні моделі писати умови за нас. А тепер з'явилась окрема модель, робота якої – вирішувати, в яку гілку if/else заходити. Коло замкнулося. Питання лише одне: навіщо це, якщо if/else безкоштовний?

## Що таке Jev насправді

TypeSafe називає Jev «першою System One моделлю» – відсилка до Канемана з його швидкою інтуїтивною «системою 1» і повільною аналітичною «системою 2». Якщо звичайні LLM – це «система 2», яка розмірковує токен за токеном, то Jev – «система 1»: миттєва відповідь без внутрішнього монологу.

Технічно за цим стоять три речі, які компанія описує в анонсі:

- **Неавторегресивна генерація.** Звичайна LLM передбачає наступний токен, потім наступний, і так сотні разів. Jev видає всі відповіді за один прохід, паралельно. Звідси і швидкість: TypeSafe заявляє 70–500 мс end-to-end.
- **Жодного тексту.** Модель фізично не вміє генерувати рядки. На виході – лише типізовані структури з наперед заданої схеми.
- **RLCD** (Reinforcement Learning for Calibrated Decisions) – метод тренування, оптимізований не під «сподобатись людині», а під чесні, калібровані ймовірності. Тобто коли модель каже «впевненість 0.9», це має статистично означати ~90% влучань.

### Три типи рішень

За [офіційною документацією](https://docs.typesafe.ai/introduction), запити до Jev складаються зі стану і набору запитань трьох типів. Усі запитання оцінюються паралельно й ізольовано за один виклик:

- **Choice** – «обери варіант зі списку». Повертає `choice`, розподіл `probabilities` і `confidence`. Класика: «який відділ має обробити цей тикет?». Обмеження: до 255 варіантів.
- **Score** – «оціни стан за рубрикою». Повертає `score`, розподіл і `confidence`. Наприклад: «наскільки токсичний цей коментар за шкалою 1–5?».
- **Noul** – «чи істинне це твердження?». Повертає одне число від 0 до 1 – ймовірність «так». Окремого поля confidence немає: у бінарного розподілу саме це число і є повним описом упевненості.

Зверни увагу, чого тут немає: генерації відповіді клієнту, реферування, «поясни свій хід думок». Jev не розмовляє. Якщо тобі потрібен текст – це до звичайних LLM, і про це чесно пише сам вендор: модель «повністю відмовляється від генерації рядків».

## Jev + TypeScript: запускаємо свій перший AI-powered if/else за 10 хвилин

Теорія теорією, але руки сверблять. Нижче – повний шлях від порожньої папки до працюючого прикладу. Обидва сніпети скомпільовані проти реального SDK версії 0.6.0 у strict-режимі TypeScript; живий виклик API я не виконував (для нього потрібен власний ключ), тож приклади виводу нижче позначені як ілюстративні.

### Крок 1 – ключ і залізне правило

Реєструйся на [console.typesafe.ai](https://console.typesafe.ai) і створи API key. Далі правило, яке не обговорюється: **ключ живе лише в змінних оточення на сервері**. Не в коді, не в git, не в React-компоненті. Створи файл `.env` і одразу додай його в `.gitignore`:

```bash
echo 'TYPESAFE_API_KEY=твій-ключ-сюди' > .env
echo '.env' >> .gitignore
```

### Крок 2 – порожній проєкт за хвилину

Потрібен Node.js 20+. Далі:

```bash
mkdir jev-typescript-demo
cd jev-typescript-demo

npm init -y
npm pkg set type=module
npm install @typesafe-ai/sdk
npm install -D typescript tsx @types/node
```

Рядок `npm pkg set type=module` – не косметика: без нього TypeScript зустріне тебе помилкою `TS1309` про top-level await. Я на це наступив, поки готував приклад, тож ти вже не мусиш.

Мінімальний `tsconfig.json`:

```json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,
    "noEmit": true,
    "types": ["node"]
  }
}
```

### Крок 3 – перший AI if/else

Створи `first.ts`. Задача максимально життєва: визначити, чи повідомлення термінове.

```ts
import { noul, TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient(); // ключ бере з process.env.TYPESAFE_API_KEY

const message = process.argv[2] ?? 'Та не горить, але бажано швидше.';

const { answers, usage } = await client.systemOne({
  state: message,
  questions: {
    isUrgent: noul('Чи потребує це повідомлення термінової реакції?', {
      true: 'Щось зламалось, хтось втрачає гроші або доступ прямо зараз',
      false: 'Питання може почекати стандартної черги',
    }),
  },
});

const probability = answers.isUrgent.noul; // number від 0 до 1

if (probability > 0.7) {
  console.log(`🔥 Терміново (${(probability * 100).toFixed(0)}%) – будимо чергового`);
} else if (probability > 0.4) {
  console.log(`🤔 Незрозуміло (${(probability * 100).toFixed(0)}%) – хай гляне людина`);
} else {
  console.log(`😴 Не горить (${(probability * 100).toFixed(0)}%) – у звичайну чергу`);
}

console.log(`Витрачено токенів: ${usage.input_tokens} (вихідні – безкоштовні)`);
```

Запуск:

```bash
npx tsx first.ts "У нас упав прод і клієнти дзвонять!"
```

Що повертає модель: об'єкт `answers`, де кожен ключ відповідає твоєму запитанню. Для Noul це одне число `noul` від 0 до 1 – одночасно і відповідь, і впевненість (у бінарного розподілу інших ступенів свободи просто немає). Плюс `usage` із витраченими токенами. Вивід виглядатиме приблизно так (ілюстративно – без ключа реальний запуск повертає 401, що я особисто перевірив):

```
🔥 Терміново (91%) – будимо чергового
Витрачено токенів: 43 (вихідні – безкоштовні)
```

Вітаю: твій if/else тепер має власний API key. Залишилося додати йому Kubernetes.

### Крок 4 – додаємо відділ: Choice і Noul разом

Одне запитання – це розминка. Сила `systemOne` у тому, що всі запитання оцінюються паралельно за один виклик. Створи `triage.ts`:

```ts
import { choice, noul, TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient();

async function triage(message: string) {
  const { answers } = await client.systemOne({
    state: message,
    questions: {
      department: choice('Який відділ має обробити це звернення?', {
        billing: 'Оплати, підписки, рахунки, повернення коштів',
        technical: 'Помилки, збої, щось не працює',
        account: 'Доступ, email, паролі, налаштування профілю',
        other: null,
      }),
      isUrgent: noul('Чи потребує звернення термінової реакції?'),
    },
  });

  // TypeScript сам знає, що department.choice – це
  // 'billing' | 'technical' | 'account' | 'other'. Спробуй одрукуватись
  // у switch нижче – компілятор упіймає.
  const department = answers.department;
  const urgent = answers.isUrgent.noul > 0.7;
  const needsHuman = department.confidence < 0.6;

  if (needsHuman) {
    return { queue: 'human-review', urgent } as const;
  }

  switch (department.choice) {
    case 'billing':
      return { queue: 'billing', urgent } as const;
    case 'technical':
      return { queue: urgent ? 'oncall' : 'technical', urgent } as const;
    case 'account':
      return { queue: 'account', urgent } as const;
    case 'other':
      return { queue: 'triage-inbox', urgent } as const;
  }
}

console.log(await triage('Не можу зайти в акаунт, а через годину демо клієнту!'));
```

```bash
npx tsx triage.ts
```

Найприємніша частина тут – типи. SDK використовує const generics: ключі, які ти передав у `choice()`, стають літеральним union-типом відповіді. `answers.department.choice` – це не `string`, а рівно `'billing' | 'technical' | 'account' | 'other'`, тому switch вище – вичерпний, і одруківка в назві гілки не переживе компіляцію. У Choice, на відміну від Noul, є окреме поле `confidence` і повний розподіл `probabilities` по всіх варіантах – саме на confidence ми вішаємо рішення «віддати людині».

Це іграшкова версія того, що в наступному розділі виросте в production-приклад із fallback-ами й обробкою помилок – не повторюватимусь, там усе є.

### Крок 5 – типові граблі

- **Забутий ключ.** Без `TYPESAFE_API_KEY` перший же виклик впаде з `AuthenticationError` (401). SDK кидає типізовані помилки – `APIError`, `RateLimitError`, `APITimeoutError` – лови їх, а не загадковий `unknown`.
- **Ключ у браузері.** Спроба створити `TypeSafeClient` у React-компоненті на клієнті – і SDK **відмовиться працювати**: у конфігу є прапорець `dangerouslyAllowBrowser`, який за замовчуванням `false`, і назва в нього така не випадково. Правильна схема для Next.js: фронт шле текст на свій Route Handler (`app/api/triage/route.ts`) або викликає Server Action, а ключ живе тільки на сервері. Для чистого React – той самий принцип із будь-яким бекендом.
- **Відсутність обробки помилок.** Дефолтний таймаут – 10 секунд, ретраїв – 2. Зовнішній сервіс у критичному шляху без try/catch і плану Б – це інцидент, який просто ще не стався.
- **Пороги «зі стелі».** 0.5 усюди – майже завжди неправильно. Поріг залежить від ціни помилки в конкретній гілці: про це детально в розділі про production нижче.
- **Сліпа довіра.** Типізована відповідь – не означає правильна. Але про це вже вся друга половина статті.

### Крок 6 – міні-челендж

Домашка на 15 хвилин, щоб помацати модель руками:

1. Додай у `triage.ts` категорію `spam` з описом на кшталт «реклама, фішинг, нерелевантні розсилки».
2. Прожени три повідомлення і подивись не лише на `choice`, а й на весь розподіл `probabilities`:
   - «Вітаємо! Ви виграли мільйон, перейдіть за посиланням» – очікувано spam?
   - «Після оновлення застосунок вилітає на старті» – technical, але наскільки термінове?
   - «ТЕРМІНОВО!!! забув пароль» – капс кричить, а чи кричить ймовірність?
3. Посунь поріг `isUrgent` з 0.7 до 0.4, потім до 0.85 – і подивись, як ті самі повідомлення мігрують між гілками.

Реальні відповіді моделі наводити не буду – у мене немає твого ключа, а вигадувати цифри в статті про калібровані ймовірності було б особливо іронічно. Проганяй – і побачиш свої.

## Спробуй сам: твій if/else тепер із AI

Читати про різницю між правилами і моделлю – одне, а потикати її пальцем – інше. Нижче – інтерактивне демо: чотири готові повідомлення клієнтів і два підходи поруч. Лівий стовпчик – справжній детермінований класифікатор на ключових словах, який виконується прямо в твоєму браузері. Правий – наперед підготовлені результати в стилі Jev для тих самих повідомлень (реальний API зі статті не викликається – і чому саме, демо чесно пояснює).

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

<!--slot:jev-demo-->

## Живий приклад: тріаж підтримки на TypeScript

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

```ts
type Routing = { department: string; urgent: boolean };

function routeTicketOldSchool(text: string): Routing {
  const lower = text.toLowerCase();

  const urgent =
    lower.includes('термінов') ||
    lower.includes('не працює') ||
    lower.includes('зламал');

  if (lower.includes('оплат') || lower.includes('рахунок')) {
    return { department: 'billing', urgent };
  }
  if (lower.includes('помилк') || lower.includes('баг')) {
    return { department: 'technical', urgent };
  }
  return { department: 'other', urgent };
}
```

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

Тепер те саме через Jev – це вже доросла версія іграшкового `triage.ts` із квікстарту: з fallback-ом, обробкою помилок і явною відмовою вгадувати. Повна документація SDK – [docs.typesafe.ai/sdk/javascript](https://docs.typesafe.ai/sdk/javascript):

```ts
import { choice, TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient(); // ключ бере з process.env.TYPESAFE_API_KEY

type Ticket = { id: string; text: string };

type TriageResult =
  | { action: 'route'; department: string; urgent: boolean }
  | { action: 'human'; reason: string };

async function triageTicket(ticket: Ticket): Promise<TriageResult> {
  try {
    const response = await client.systemOne({
      model: 'jev-latest',
      state: { document: ticket.text },
      questions: {
        department: choice('Який відділ має обробити це звернення?', {
          billing: null,
          technical: null,
          account: null,
          other: null,
        }),
        isUrgent: {
          type: 'noul',
          instructions: 'Чи потребує звернення термінової реакції?',
          criteria: {
            true: 'Клієнт втратив доступ чи гроші, або сервіс не працює',
            false: 'Питання може почекати стандартної черги',
          },
        },
      },
    });

    const department = response.answers.department;
    const urgent = response.answers.isUrgent.noul > 0.7;

    // Патерн confidence-gated routing з офіційної документації:
    // нижче 0.6 впевненості – не вгадуємо, а віддаємо людині.
    if (department.confidence < 0.6) {
      return { action: 'human', reason: 'low-confidence routing' };
    }

    return { action: 'route', department: department.choice, urgent };
  } catch (error) {
    // API недоступне – деградуємо до детермінованих правил,
    // а не кладемо чергу підтримки разом із зовнішнім сервісом.
    const fallback = routeTicketOldSchool(ticket.text);
    return { action: 'route', ...fallback };
  }
}
```

Кілька чесних приміток до коду:

- Приклад зібраний за офіційною документацією та типами SDK; я не ганяв його у production і не маю власних метрик – коли будеш впроваджувати, почни з playground у консолі TypeSafe.
- Поріг `0.7` для Noul – не магія, а компроміс із [гайда по порогах](https://docs.typesafe.ai/primitives/noul): піднімай його, коли хибне «так» дороге (дарма розбудити чергового), опускай, коли дороге пропущене «так» (не помітити реальну пожежу).
- try/catch тут не декорація. Зовнішній сервіс у критичному шляху – це нова точка відмови, і твій fallback має бути написаний до першого інциденту, а не після.

Різниця з if/else концептуальна: ти більше не перелічуєш формулювання, якими люди описують проблему. Ти описуєш **критерії рішення**, а розпізнавання формулювань – проблема моделі.

## Де це реально застосовують

**1. Роутинг в AI-агентах.** Найпопулярніший кейс у [гайдах Vercel](https://vercel.com/kb/guide/typesafe-jev-and-ai-sdk): агентський цикл на кожній ітерації вирішує «який інструмент викликати далі», «продовжити, перепитати чи зупинитись». Ці рішення відбуваються десятки разів на сесію, і ганяти заради кожного велику LLM – дорого і повільно. AI SDK 7 виставляє Jev через експериментальний `evaluate` API. Обмеження: якщо рішення потребує міркування на кілька кроків – це знову задача для «системи 2».

**2. Тріаж підтримки.** Розібраний вище. Виграш у порівнянні з малою LLM – швидкість, ціна і калібрована впевненість замість «JSON, який теж треба валідувати». Коли НЕ треба: якщо у тебе три категорії і чіткі формальні ознаки – звичайні правила дешевші й пояснюваніші.

**3. Запобіжник для coding-агентів.** LangChain у [своєму матеріалі](https://www.langchain.com/blog/building-a-harness-with-jev) показує `AutoModeMiddleware`: перед виконанням tool call агента Jev оцінює, чи не робить той щось ризиковане, і блокує виклик до виконання. Важлива межа, яку варто промовити вголос: **імовірнісна модель не може бути єдиним запобіжником**. `rm -rf` у проді має зупиняти детермінований allowlist і права доступу, а Jev – це додатковий шар для сірих зон, не заміна їм.

**4. Оцінка виходів інших моделей.** LLM-as-a-judge – звична практика, але суддя-LLM повільний і сам схильний до галюцинацій у вільному тексті. Jev у ролі судді повертає рівно те, що потрібно пайплайну: score за рубрикою і ймовірність «відповідь відповідає джерелам». Це ж основа guardrail-сценаріїв, які TypeSafe називає серед основних.

**5. Модерація контенту.** Noul («чи порушує це правило X?») плюс поріг, нижче якого кейс іде людині-модератору. Патерн той самий, що в тріажі: модель фільтрує очевидне, людина розбирає неоднозначне. Тут особливо важлива калібровка: некаліброване «0.93» у модерації – це юридична проблема, а не технічна.

**6. Автоматизація пошти й workflow.** А ось тут – чесна крапля скепсису. Якщо твій сценарій «раз на годину класифікувати листи в CRM», то виграш Jev у латентності тобі байдужий: лист і так лежить у черзі. Мала LLM зі structured output або навіть звичайний класифікатор впораються, а різницю у вартості на таких обсягах ти не помітиш. Jev починає мати сенс на великих потоках і в реальному часі – map-reduce по мільйону документів, а не по десяти листах.

## Швидкість і ціна: що заявлено, а що перевірено

Цифри, які розійшлись заголовками: **193.6x швидше і 444.6x дешевше** за LLM. Тут потрібна чесність, якої часто бракує оглядам:

- Це результати [власних workflow-евалів TypeSafe](https://typesafe.ai/blog/introducing-system-one-models-and-jev) на пропрієтарних задачах бізнес-автоматизації, зібраних власною командою. Незалежних публічних бенчмарків на момент написання немає, і компанія сама визнає можливий bias.
- Порівняння 70 мс проти «3–329 секунд у frontier-моделей» на Hacker News одразу назвали [порівнянням теплого з м'яким](https://news.ycombinator.com/item?id=49767192): великі моделі в цих замірах виконують значно ширшу роботу.
- Прайс справжній і простий: **$0.042 за мільйон вхідних токенів, вихідні – безкоштовно** (їх там і генерувати нічого). Це на порядки нижче за frontier-моделі, але порівнювати чесно треба з малими LLM і класифікаторами, а не з найдорожчим у меню.

Концептуальна таблиця замість вигаданих чисел:

| Підхід | Латентність | Вартість | Детермінізм | Обслуговування |
|---|---|---|---|---|
| if/else + правила | наносекунди | безкоштовно | повний | росте з кількістю правил |
| Класичний ML-класифікатор | мілісекунди | хостинг | ні, але стабільний | датасет + перетренування |
| Мала LLM + structured output | секунди | низька | ні | промпти + валідація JSON |
| Frontier LLM | секунди-хвилини | висока | ні | промпти, але вміє міркувати |
| Jev | 70–500 мс* | $0.042/MTok* | ні, але калібрований | критерії замість правил |

\* – заявлені вендором значення, незалежно не підтверджені.

Головний trade-off не в цифрах: правила пояснювані на 100% («зайшло в цю гілку, бо substring»), Jev – ні. Якщо тобі потрібно пояснити регулятору, чому заявку відхилено, «модель була впевнена на 0.87» – погана відповідь.

## Що кажуть розробники

Тред на Hacker News – обов'язкове читання перед впровадженням. Три найгучніші лінії:

**«Це ж просто дорогий BERT-класифікатор?»** Найчастіший скепсис. Найкраще формулювання з треду: «It is BERT-like, but with the data, compute, and training recipe of modern LLMs». Тобто так, ідея zero-shot класифікації не нова – [KDnuggets прямо пише](https://www.kdnuggets.com/what-everyone-is-getting-wrong-about-typesafe-ais-jev): «Classification is not new. Intent detection is not new». Нове – пакування: zero-shot, без датасету і файнтюна, з калібровкою і за одну ціну.

**«Zero hallucinations – маркетинг».** І це правда, з уточненням. Jev гарантує нуль **out-of-schema** відповідей: він фізично не може повернути варіант поза твоїм списком. Але він може впевнено обрати **неправильний** варіант зі списку – що CEO TypeSafe чесно визнав у тому ж треді. «Типобезпечно» не означає «правильно»; компілятор TypeScript теж пропускає логічні баги.

**«Чому не написати звичайні правила?»** Бо іноді – треба написати звичайні правила, і це буде правильна відповідь. Межа проста: правила виграють, коли ознаки формальні (сума > X, домен у списку), Jev доречний, коли рішення залежить від сенсу неструктурованого тексту. Спроба покрити природну мову регулярками – це той самий if/else, тільки з нескінченним беклогом edge cases.

Заради справедливості: заголовок анонсу «нова frontier-модель у 40–400 разів дешевша» модератори HN перейменували протягом години – маркетингова упаковка запуску викликала не менше дискусій, ніж технологія.

## Чи брав би я це в production

Відповідь інженера: не раніше, ніж поміряю. Ось як виглядав би чесний eval для того ж тріажу підтримки:

1. **Зібрати розмічений датасет** із реальних звернень: 300–500 прикладів, категорії проставлені людьми, спірні кейси – окремо.
2. **Прогнати три системи:** чинні правила, малу LLM зі structured output і Jev. Однакові дані, однакові категорії.
3. **Поміряти чотири речі:** якість (окремо false positives і false negatives – у тріажі пропущена «пожежа» коштує дорожче, ніж зайва ескалація), латентність p50/p95, повну вартість на місячному обсязі, і – найнедооціненіше – **вартість підтримки**: скільки годин на місяць їстиме кожен варіант.
4. **Перевірити калібровку на своїх даних.** Взяти всі відповіді з confidence 0.8–0.9 і подивитись реальну частку влучань. Якщо вона не ~85%, пороги з документації для тебе не працюють, і їх треба рухати за власною статистикою.
5. **Спроєктувати відмову заздалегідь:** що робить система, коли API лежить, коли confidence стабільно низька, коли модель систематично плутає дві категорії. Fallback-гілка з детермінованих правил + черга на людину – мінімум, без якого зовнішню модель у критичний шлях ставити не можна.

І ключова думка для сеньйорів, яку варто забрати з собою навіть якщо Jev тобі не потрібен: **структурований вихід ≠ правильне рішення**. Уся цінність типізації тут – у тому, що помилки стають вимірюваними і керованими порогами. Але міряти їх – досі твоя робота.

Якщо тема AI-інструментів у щоденній роботі тобі цікава ширше – у мене є розбори [як використовувати AI без деградації інженерного мислення](/blog/ai-dlia-prohramista), [чекліст перевірки AI-згенерованого коду](/blog/ai-kod-chek-list-perevirky) і [що таке MCP простими словами](/blog/mcp-prostymy-slovamy).

## Замість висновку

Спочатку ми писали if/else руками. Потім навчили нейромережі писати if/else за нас. Тепер ми викликаємо спеціально натреновану модель, щоб вона вирішила, в яку гілку if/else зайти – і платимо за кожну умову токенами. Щоправда, вихідні токени у Jev безкоштовні, тож формально нам платити лише за те, щоб машина нас вислухала. У цьому щось є.

Якщо серйозно: Jev – цікавий приклад спеціалізації замість універсальності. Не «розумніша модель», а вужча, швидша і чесніша про власну невпевненість. Чи виживе окрема категорія «System One моделей», чи цю нішу з'їдять малі LLM – покажуть незалежні бенчмарки, яких поки що просто немає. А доти нехай рішення «чи тягнути це в прод» приймає не хайп і не скепсис, а твій власний eval на твоїх власних даних.

Бо це, на щастя, поки що детермінований процес.