Skip to content

Instantly share code, notes, and snippets.

@ivan-hilckov

ivan-hilckov/part1-video.md

Last active February 28, 2026 23:10
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save ivan-hilckov/c5cd3927c355d9a3e059a61c5229c194 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save ivan-hilckov/c5cd3927c355d9a3e059a61c5229c194 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. ivan-hilckov revised this gist Feb 28, 2026. 1 changed file with 193 additions and 0 deletions.
    193 changes: 193 additions & 0 deletions part1-video.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,193 @@
    # 🎬 Часть 1: Разбор видео по таймкодам

    **Видео:** ['Prompting' Just Split Into 4 Skills](https://www.youtube.com/watch?v=BpibZSMGtdY)
    **Автор:** Nate B Jones (AI News & Strategy Daily)

    ---

    ## 00:00 — Если промптишь как месяц назад — уже отстаёшь

    Opus 4.6, Gemini 3.1 Pro, GPT 5.3 Codex — все выпущены за последние недели с автономными агентными возможностями. Эти модели работают автономно **часами, днями, неделями** без проверки.

    Слово "промптинг" теперь скрывает **4 разных навыка**, большинство практикует только один. Разрыв между теми кто видит все 4 слоя и теми кто практикует один — уже **10x и растёт**.

    **→ Вывод:** Всё что ты делал в чате (ловил ошибки, давал контекст, корректировал курс) — теперь должно быть закодировано ДО старта агента.

    ---

    ## 02:30 — Разрыв 10x: Та же модель, тот же вторник, разные навыки

    **Человек A (навыки 2025):**
    - Пишет запрос → получает 80% готовый результат → 40 минут чистит → доволен

    **Человек B (навыки 2026):**
    - Пишет структурированную спецификацию за 11 минут → отдаёт агенту → идёт за кофе → возвращается к готовому результату → делает 5 таких дек до обеда

    Та же модель, тот же день — **недельная работа за утро**.

    **→ Вывод:** Инвестировать время в написание спецификации ПЕРЕД запуском агента.

    ---

    ## 05:15 — Тоби Лютке о Context Engineering

    CEO Shopify — технический лидер, глубоко изучает AI.

    **Его определение:** *"Способность сформулировать проблему с достаточным контекстом так, что без дополнительной информации задача становится решаемой"*

    Это НЕ про хитрые трюки промптов — это **коммуникационная дисциплина**.

    **Побочный эффект:** Его emails стали чётче, memo — лучше, decision-making frameworks — сильнее.

    **Провокационный тезис:** Много "политики" в компаниях — это просто плохой context engineering между людьми.

    **→ Вывод:** Применять этот навык не только к AI, но и к коммуникации с людьми.

    ---

    ## 07:45 — Фреймворк четырёх дисциплин

    Промптинг разделился на **4 различных дисциплины**:

    1. **Prompt Craft** — базовые навыки промптинга
    2. **Context Engineering** — курирование токенов в контексте
    3. **Intent Engineering** — кодирование целей и ценностей
    4. **Specification Engineering** — документы для автономного исполнения

    Они **накапливаются** — если пропустишь одну, создашь типичные enterprise-провалы.

    ---

    ## 09:30 — Дисциплина 1: Prompt Craft как базовый уровень

    Это **оригинальный навык** — то чему учили последние 2 года. Синхронный, сессионный, индивидуальный.

    **Компоненты:**
    - Чёткие инструкции
    - Релевантные примеры
    - Guardrails
    - Формат вывода
    - Разрешение конфликтов

    **Prompt craft НЕ устарел** — он стал **table stakes** (базовым требованием).

    **Аналогия:** Как умение печатать 10 пальцами — раньше конкурентное преимущество, теперь просто ожидается.

    **→ Вывод:** Если не умеешь писать чёткий промпт в 2026 — ты как человек в 1998 который не умел отправить email.

    ---

    ## 12:00 — Дисциплина 2: Context Engineering

    **Определение:** *"Стратегии курирования и поддержания оптимального набора токенов во время LLM-задачи"*

    Harrison Chase (LangChain): *"Всё есть context engineering — это описывает всё что мы делали не зная термина"*

    **Масштаб:**
    - Твой промпт = 200 токенов
    - Контекстное окно = 1 миллион
    - Твои 200 токенов = **0.002%** того что видит модель

    **Включает:** system prompts, tool definitions, retrieved documents, message history, memory systems, MCP connections

    **Ключевой инсайт:** LLM деградируют с ростом информации. Важно включать **релевантные** токенов.

    **→ Вывод:** Люди которые эффективнее в 10x — не пишут в 10x лучшие промпты, они строят в **10x лучшую контекстную инфраструктуру**.

    ---

    ## 15:20 — Дисциплина 3: Intent Engineering

    - Context engineering говорит агентам **что знать**
    - Intent engineering говорит агентам **чего хотеть**

    Практика кодирования: organizational purpose, goals, values, trade-off hierarchies, decision boundaries.

    **Кейс Klarna:**
    - AI-агент обработал 2.3 миллиона разговоров за первый месяц
    - Оптимизировал не то — сократил время решения, но не оптимизировал customer satisfaction
    - Пришлось нанимать людей обратно

    **Позиция в стеке:** Intent engineering над context engineering как strategy над tactics.

    **→ Вывод:** Провалы на высших уровнях серьёзнее — ошибка в intent engineering = проблемы для всей компании.

    ---

    ## 17:45 — Дисциплина 4: Specification Engineering

    Практика написания документов которые автономные агенты могут исполнять **часами/днями без человека**.

    Это уровень ВЫШЕ всего описанного — это не про подготовку работы для агента, это про **весь информационный корпус организации как agent-readable**.

    **Пример Anthropic с Opus 4.5:**
    - Дали агенту "build a clone of Claude.ai"
    - Агент пытался сделать слишком много сразу → закончился контекст
    - Решение: specification engineering — laser agent ставит environment, progress log документирует, coding agent делает incremental progress

    **→ Вывод:** Corporate strategy = specification. Product strategy = specification. OKRs = specification. Всё должно быть agent-readable.

    ---

    ## 22:30 — Почему long-running агенты ломают синхронные assumptions

    Ментальная модель "промптинг = хорошие инструкции для AI" **провалится**.

    Эта модель предполагает синхронное взаимодействие:
    - Ты видишь output в real-time
    - Исправляешь ошибки
    - Даёшь дополнительный контекст

    Long-running агенты ломают КАЖДОЕ из этих предположений.

    **Planner-worker архитектура доминирует:**
    - Capable model планирует работу
    - Decomposition на subtasks
    - Acceptance criteria
    - Дешёвые/быстрые модели исполняют

    **Ключевой сдвиг:** От "поправлю в real-time" к "spec должен быть правильным до старта"

    ---

    ## 25:00 — Пять примитивов Specification Engineering

    ### Примитив 1: Self-Contained Problem Statements
    Можешь ли сформулировать проблему так что агенту не нужно искать дополнительную информацию?

    **Тренировка:** Возьми "update dashboard to show Q3 numbers" и перепиши как будто получатель никогда не видел dashboard.

    ### Примитив 2: Acceptance Criteria
    Если не можешь описать что такое "done" — агент не знает когда остановиться.

    **Тренировка:** Для каждой задачи напиши 3 предложения для independent verify без вопросов.

    ### Примитив 3: Constraint Architecture
    4 категории: musts, must-nots, preferences, escalation triggers.

    **Тренировка:** Запиши что smart person мог бы сделать что technically satisfies но produces wrong outcome.

    ### Примитив 4: Decomposition
    Large tasks → components executable independently, testable independently.

    **Тренировка:** Проект на несколько дней → subtasks каждый <2 часов.

    ### Примитив 5: Evaluation Design
    Не "looks reasonable" а можешь ли доказать measurably consistently что это хорошо.

    **Тренировка:** 3-5 test cases с known good outputs, запускай после model updates.

    ---

    ## 36:20 — С чего начать: Прогрессия

    1. **Закрой gap в prompt craft** — перечитай документацию, пройди tutorials
    2. **Построй personal context layer** — напиши claude.md эквивалент
    3. **Практикуй specification engineering** — real project, не toy problem
    4. **Строй intent infrastructure** — кодируй decision frameworks

    **Критично:** Это не лестница где можно бросить нижние ступени. Это **stack** где каждый layer делает возможным layers выше.

    ---

    *Дата: 28 февраля 2026*
  2. ivan-hilckov revised this gist Feb 28, 2026. 1 changed file with 131 additions and 0 deletions.
    131 changes: 131 additions & 0 deletions part2-themes.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,131 @@
    # 📊 Часть 2: Ключевые темы — Что делаем | Что НЕ делаем

    ---

    ## 1. Почему prompt craft стал table stakes, а specification engineering определяет quality ceiling

    | ✅ Что делаем | ❌ Что НЕ делаем |
    |--------------|-----------------|
    | Владеем prompt craft на отлично как базовым навыком | Не считаем prompt craft достаточным для differentiation |
    | Инвестируем время в specification ДО запуска агента | Не полагаемся на real-time исправления |
    | Думаем о quality ceiling как о качестве spec | Не ожидаем что модель "догадается" |
    | Пишем complete, structured, internally consistent descriptions | Не даём vague high-level prompts на long-running tasks |
    | Описываем outcome с precision и completeness | Не оставляем implicit assumptions |
    | Практикуем 5 примитивов specification engineering | Не останавливаемся на "80% готово" |

    **Суть:** Prompt craft — как умение печатать. Необходимо, но не differentiator. Specification engineering — это где создаётся value в 2026.

    ---

    ## 2. Как context engineering Тоби Лютке делает его emails чётче и memos лучше

    | ✅ Что делаем | ❌ Что НЕ делаем |
    |--------------|-----------------|
    | Формулируем проблемы self-contained | Не полагаемся на shared context который не существует |
    | Включаем всё что нужно для plausibly solvable task | Не ожидаем что получатель "заполнит gaps" |
    | Поверхностные разногласия → explicit assumptions | Не позволяем disagreements становиться "политикой" |
    | Применяем discipline к human-to-human communication | Не ограничиваем skill только AI interactions |
    | Рассматриваем AI forcing function как gift | Не сопротивляемся требованию к clarity |
    | Пишем как для человека без любого контекста | Не предполагаем что коллеги знают что мы имеем в виду |

    **Суть:** Context engineering — это communication discipline. AI заставляет нас быть чёткими, и это улучшает ВСЮ коммуникацию, включая human-to-human.

    ---

    ## 3. Как выглядят 5 примитивов specification engineering на практике

    | Примитив | ✅ Что делаем | ❌ Что НЕ делаем |
    |----------|--------------|-----------------|
    | **Self-contained statements** | Переписываем как для человека без контекста | Не пишем "update dashboard to show Q3 numbers" |
    | **Acceptance criteria** | 3 предложения для independent verify | Не оставляем "done" неопределённым |
    | **Constraint architecture** | musts, must-nots, preferences, escalation triggers | Не полагаемся на implicit understanding |
    | **Decomposition** | <2h tasks с clear boundaries | Не даём monolithic multi-day tasks |
    | **Evaluation design** | 3-5 test cases с known good outputs | Не оцениваем по "looks reasonable" |

    ### Практические примеры:

    **Self-contained (плохо → хорошо):**
    ```
    ❌ "Update dashboard to show Q3 numbers"
    ✅ "Update sales dashboard at /analytics/sales:
    - Add Q3 2026 revenue (from sales_db.quarterly_revenue where quarter='Q3' AND year=2026)
    - Format: $X.XM with YoY comparison percentage
    - Position: top-right card, same style as Q2 card
    - Color: green if +YoY, red if -YoY"
    ```

    **Acceptance criteria (плохо → хорошо):**
    ```
    ❌ "Build a login page"
    ✅ "Build a login page that:
    1. Handles email+password with validation (email format, password 8+ chars)
    2. Supports social OAuth via Google and GitHub
    3. Shows 2FA input only after successful first factor
    4. Persists session for 30 days with "remember me"
    5. Rate limits to 5 failed attempts per 15 minutes per IP"
    ```

    **Constraint architecture:**
    ```
    MUSTS:
    - Use existing auth service at /api/auth
    - Follow design system components from @ui/components
    MUST-NOTS:
    - Never store passwords in plain text
    - Never modify user table schema
    PREFERENCES:
    - Prefer server-side validation over client-only
    - Prefer progressive disclosure for complex forms
    ESCALATE:
    - Any changes to security-critical code
    - Performance regressions >100ms
    ```

    ---

    ## 4. Где живёт 10x gap между теми кто видит все 4 layers и теми кто практикует только один

    | Аспект | ✅ 10x люди | ❌ 1x люди |
    |--------|-----------|-----------|
    | **Видение** | Prompting как 4-layer stack | Prompting = chat instructions |
    | **Инфраструктура** | Context/intent/spec infrastructure готова | Каждый раз с нуля |
    | **Результат** | Неделя работы за утро | "Сэкономил 50% времени" |
    | **Качество** | 100% готово, agent работает пока пьём кофе | 80% готово, 40 минут cleanup |
    | **Документы** | Agent-readable specifications | Документы "для людей" |
    | **Oversight** | Encoded в spec до старта | Real-time corrections |

    ### Конкретный пример разрыва:

    **1x человек (2025 skills):**
    ```
    Утро понедельника:
    09:00 - Открыл Claude, написал "create presentation about Q3 results"
    09:05 - Получил черновик, начал править
    09:45 - Закончил cleanup, презентация готова
    → Сэкономил ~1.5 часа, доволен
    Итого за день: 3-4 презентации/документа
    ```

    **10x человек (2026 skills):**
    ```
    Утро понедельника:
    09:00 - Загрузил context (claude.md + project specs)
    09:05 - Написал structured specification (11 минут)
    09:16 - Запустил агента, пошёл за кофе
    09:25 - Вернулся к готовой презентации, проверил по acceptance criteria
    09:30 - Запустил следующую задачу
    Итого за день: 15-20 презентаций/документов
    ```

    **Разница:** Не в том что один "умнее". А в том что один видит 4 layer stack, другой — только prompt craft.

    ---

    *Дата: 28 февраля 2026*
  3. ivan-hilckov revised this gist Feb 28, 2026. 1 changed file with 195 additions and 0 deletions.
    195 changes: 195 additions & 0 deletions part3-answers.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,195 @@
    # 🎯 Часть 3: Ответы на ключевые вопросы

    ---

    ## Вопрос 1: Что надо подтянуть / изучить / понимать чтобы быть успешным AI-инженером в 2026?

    ### Уровень 1: Prompt Craft (table stakes)

    **Изучить:**
    - Документация Anthropic по промптингу
    - OpenAI prompt engineering guide
    - Google AI prompting best practices

    **Практика:**
    - Пройти интерактивные tutorials (AI Cred)
    - Создать folder регулярных задач с best prompts
    - Сохранять outputs как baseline, revisit over time

    **Понимать:**
    - Это БАЗОВЫЙ уровень, не differentiator
    - Без этого — как без email в 1998

    ---

    ### Уровень 2: Context Engineering

    **Изучить:**
    - Anthropic's foundational piece (сентябрь 2025)
    - LangChain approach к context management
    - MCP (Model Context Protocol)

    **Практика:**
    - Создать свой claude.md / personal context layer
    - Описать: goals, constraints, communication preferences, quality standards
    - Загружать context в начале КАЖДОЙ AI сессии

    **Понимать:**
    - Твой промпт = 0.002% контекстного окна
    - Контекст делает тяжёлую работу, не промпт
    - 10x люди строят 10x лучшую context infrastructure, не пишут 10x лучшие промпты

    ---

    ### Уровень 3: Intent Engineering

    **Изучить:**
    - Кейс Klarna (2.3M разговоров, wrong optimization)
    - Trade-off hierarchies
    - Decision boundaries для AI

    **Практика:**
    - Кодировать decision frameworks команды
    - Определить "что такое достаточно хорошо" для категорий работы
    - Написать что agent решает сам vs эскалирует

    **Понимать:**
    - Intent engineering над context engineering как strategy над tactics
    - Ошибки здесь = проблемы для всей компании
    - Можно иметь идеальный контекст и ужасный intent alignment

    ---

    ### Уровень 4: Specification Engineering

    **Изучить 5 примитивов:**
    1. Self-contained problem statements
    2. Acceptance criteria
    3. Constraint architecture (musts, must-nots, preferences, escalation)
    4. Decomposition (<2h tasks)
    5. Evaluation design (test cases с known good outputs)

    **Практика:**
    - Взять REAL project (не toy problem)
    - Написать spec ПЕРЕД использованием AI
    - Думать о document corpus как agent-readable

    **Понимать:**
    - Это ВЫСШИЙ уровень
    - Practical skill: описать outcome с precision чтобы система исполняла дни/недели
    - Corporate strategy = specification. OKRs = specification.

    ---

    ### Mindset Shifts (критично!)

    | От (2025) | К (2026) |
    |-----------|----------|
    | "Я поправлю в real-time" | "Spec должен быть правильным до старта" |
    | "80% готово = успех" | "Agent работает без меня" |
    | Individual skill | Organizational infrastructure |
    | Синхронное взаимодействие | Асинхронное, long-running |
    | "Сэкономил 50% времени" | "Неделя за утро" |

    ---

    ## Вопрос 2: Чем отличается подход 2025 от 2026?

    ### Таблица различий

    | Аспект | 2025 (устаревший) | 2026 (актуальный) |
    |--------|-------------------|-------------------|
    | **Модель взаимодействия** | Синхронная, сессионная, chat-based | Асинхронная, long-running, autonomous |
    | **Длительность задач** | Минуты | Часы, дни, недели |
    | **Роль человека** | Real-time oversight, course correction | Spec написан до старта, oversight encoded |
    | **Определение успеха** | "Сэкономил 50% времени, 80% готово" | "Неделя работы за утро, 100% готово" |
    | **Где создаётся качество** | В iterative refinement в chat | В quality спецификации до старта |
    | **Bottleneck skill** | Verbal fluency, quick iteration | Completeness of thinking, edge case anticipation |
    | **Инфраструктура** | Каждый раз с нуля | Context/intent/spec infrastructure |
    | **Document corpus** | Для людей | Agent-readable specifications |
    | **Архитектура** | Human-in-the-loop | Planner-worker (plan → decompose → execute) |

    ---

    ### Что инженеры делают НЕ ТАК (2025 mistakes)

    **1. Полагаются на real-time oversight**
    ```
    ❌ "Я увижу output и поправлю"
    ✅ "Всё что нужно поправить — encoded в spec до старта"
    ```

    **2. Дают vague high-level prompts**
    ```
    ❌ "Build me a dashboard"
    ✅ 11-минутная structured specification с acceptance criteria
    ```

    **3. Не инвестируют в infrastructure**
    ```
    ❌ Каждый раз объясняют контекст заново
    ✅ claude.md + intent framework + spec templates готовы
    ```

    **4. Останавливаются на prompt craft**
    ```
    ❌ "Я хорошо промпчу, этого достаточно"
    ✅ Prompt craft — table stakes. Value в specification engineering.
    ```

    **5. Не decompose задачи**
    ```
    ❌ "Сделай мне весь проект"
    ✅ Decomposition на <2h tasks с clear boundaries
    ```

    ---

    ### Почему подходы 2025 дают меньше эффекта?

    **Structural vulnerability:** Вся модель построена на assumption **синхронного взаимодействия**.

    Ты полагаешься на:
    | Assumption 2025 | Реальность 2026 |
    |-----------------|-----------------|
    | Вижу output в real-time | Агенты работают часами/днями |
    | Исправляю ошибки сразу | Ошибки накапливаются без тебя |
    | Даю контекст когда модель спросит | Агент не спрашивает, угадывает |
    | Course correct когда drift | Drift уже произошёл к моменту когда видишь |

    ---

    ### Ключевая ошибка

    > **Thinking of AI as a chat partner instead of a worker.**
    В 2025 AI был **собеседником** — ты итерируешь в диалоге.

    В 2026 AI стал **работником** — ты даёшь spec, он исполняет автономно.

    **Аналогия:**
    - 2025: Ты сидишь с junior dev и pair-программируешь
    - 2026: Ты пишешь technical spec, отдаёшь команде, они работают неделю

    Разные навыки. Разный output. 10x gap.

    ---

    ## Финальная выжимка

    > *"The prompt by itself is dead. The specification, the context, the organizational intent — that is where the value in prompting is moving toward."*
    **Skill of providing high-quality input to intelligent systems** оказывается translatable:
    - Для AI агентов
    - Для human коллег
    - Для организационной clarity

    Это **fundamental skill of the agent age**.

    Люди которые освоят все 4 дисциплины станут лидерами где и агенты и люди perform at their ceilings.

    Остальные будут wondering why their AI investments produce partial value.

    ---

    *Дата: 28 февраля 2026*
  4. ivan-hilckov created this gist Feb 28, 2026.
    1,444 changes: 1,444 additions & 0 deletions video-summary-prompting-2026.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,1444 @@
    # Детальное саммари: "The Four Disciplines of Prompting in 2026"

    ## 🎯 Главная идея

    Промптинг в 2026 году — это уже не одна навык, а **четыре отдельные дисциплины**. Большинство людей практикуют только одну из них, что создает 10x разрыв в эффективности между теми, кто понимает все четыре уровня, и теми, кто застрял на первом.

    ---

    ## 📍 Ключевые моменты (по таймкодам)

    ### 00:00 — Если ты промптишь как в прошлом месяце, ты уже опоздал

    **Что обсуждалось:**
    - Opus 4.6, Gemini 3.1 Pro и GPT 5.3 Codex вышли в последние недели с возможностями автономных агентов
    - Модели теперь работают **автономно часами и днями** без проверки со стороны человека
    - Промптинг на основе чат-взаимодействия стал функционально устаревшим для серьезной работы
    - Слово "промптинг" теперь скрывает четыре совершенно разных набора навыков
    - Разрыв между теми, кто видит все четыре уровня, и теми, кто не видит, уже достиг 10x и продолжает расти

    **Вывод — что делать, чтобы быть лучшим:**
    - Перестать думать о промптинге как о разговоре с чат-ботом
    - Понять, что AI теперь — это **worker** (работник), а не chat partner (партнер по чату)
    - Обновить свое понимание промптинга каждый месяц, следя за новыми моделями
    - Принять, что все что вы привыкли делать в режиме реального времени (исправление ошибок, добавление контекста, коррекция курса) теперь должно быть **закодировано заранее, до того как агент начнет работу**

    ---

    ### 02:30 — Разрыв в 10x: одна модель, один вторник, разные навыки

    **Что обсуждалось:**
    Конкретный пример двух людей в один и тот же вторник, с одной и той же моделью:

    **Человек А (навыки 2025):**
    - Запрашивает PowerPoint презентацию
    - Получает результат на 80% правильный
    - Тратит 40 минут на исправление (форматирование, шрифты, стиль)
    - Экономит время — задача заняла бы 2-3 часа вручную
    - Это хороший результат для 2025

    **Человек Б (навыки 2026):**
    - Пишет структурированную спецификацию за 11 минут
    - Передает ее автономному агенту
    - Идет пить кофе
    - Возвращается к готовой презентации, соответствующей всем критериям качества
    - **Делает 5 таких презентаций до обеда**
    - Выполняет недельную работу за утро

    **Разница: 10x производительность. Одна модель. Один вторник.**

    **Вывод — что делать, чтобы быть лучшим:**
    - Инвестировать время в написание полной спецификации **до** того, как дать задачу AI
    - Научиться тратить больше времени на промпт (11 минут vs 2 минуты), но получать результат который не требует исправлений
    - Думать о AI как о работнике, которому нужна полная спецификация, а не как о помощнике в реальном времени
    - Измерять эффективность не по времени одной итерации, а по количеству **завершенных задач без доработок**

    ---

    ### 05:15 — Toby Lütke о контекст-инжиниринге как дисциплине коммуникации

    **Что обсуждалось:**
    - Toby Lütke (CEO Shopify) — технический CEO, который глубоко погружен в AI
    - У него есть папка промптов, которые он прогоняет через каждый новый релиз модели
    - Он использует термин **"context engineering"** (контекст-инжиниринг)

    **Определение Toby:**
    > Фундаментальный навык — это способность сформулировать проблему с достаточным контекстом таким образом, что **без какой-либо дополнительной информации** задача становится решаемой.
    **Влияние на личную эффективность:**
    - Toby отметил, что необходимость давать AI полный контекст улучшила его **коммуникацию как CEO**
    - Его **emails стали более сжатыми**
    - Его **меморандумы стали лучше**
    - Его **фреймворки принятия решений стали сильнее**

    **Провокационная гипотеза Toby:**
    > Многое из того, что люди в больших компаниях называют **"политикой"**, на самом деле является **плохим контекст-инжинирингом для людей**.
    **Объяснение:**
    - Хороший контекст-инжиниринг выявляет разногласия по допущениям, которые никогда не формулируются явно
    - Эти невысказанные допущения проявляются как политика и обиды в больших компаниях
    - Это происходит потому, что люди склонны быть небрежными коммуникаторами, полагаясь на общий контекст, **который на самом деле не существует**

    **Вывод — что делать, чтобы быть лучшим:**
    - Практиковать **self-contained problem statements** (самодостаточные формулировки проблем)
    - Перед тем как дать задачу AI или человеку, спросить себя: "Есть ли у получателя ВСЯ информация, необходимая для решения этой задачи?"
    - Выявлять скрытые допущения и делать их явными
    - Понять, что улучшение навыков промптинга для AI автоматически улучшает вашу коммуникацию между людьми
    - Рассматривать плохую коммуникацию в организации как техническую проблему (недостаток контекста), а не как политическую

    ---

    ### 07:45 — Фреймворк четырех дисциплин

    **Что обсуждалось:**
    Промптинг больше не единая навык. Это **четыре отдельные дисциплины**, каждая на разной высоте и временном горизонте:

    **1. Prompt Craft (Ремесло промптов)**
    - **Что:** Синхронная, сессионная, индивидуальная навык
    - **Когда:** Сидишь в чат-окне, пишешь инструкцию, оцениваешь вывод, итерируешь
    - **Статус в 2026:** Table stakes (базовый уровень), как умение печатать 10 пальцами

    **2. Context Engineering (Контекст-инжиниринг)**
    - **Что:** Курирование и поддержание оптимального набора токенов во время задачи LLM
    - **Фокус:** Вся информационная среда, в которой работает агент (system prompts, tool definitions, retrieved documents, message history, memory systems, MCP connections)
    - **Статус в 2026:** Где сейчас сфокусировано внимание индустрии

    **3. Intent Engineering (Инжиниринг намерений)**
    - **Что:** Кодирование организационных целей, ценностей, иерархий компромиссов, границ принятия решений в инфраструктуру
    - **Метафора:** Context engineering говорит агентам **что знать**. Intent engineering говорит агентам **чего хотеть**
    - **Статус в 2026:** Критично для долгоживущих автономных агентов

    **4. Specification Engineering (Инжиниринг спецификаций)**
    - **Что:** Написание документов, которые автономные агенты могут выполнять в течение продолжительного времени без вмешательства человека
    - **Масштаб:** Весь информационный корпус организации как agent-fungible (пригодный для агентов)
    - **Статус в 2026:** Только начинаем говорить об этом, но лучшие практики уже так делают

    **Ключевая идея:**
    Эти дисциплины **накапливаются**. Нельзя пропустить одну. Каждая следующая строится на предыдущей.

    **Вывод — что делать, чтобы быть лучшим:**
    - Понять, что промптинг — это не одна навык, а стек из четырех
    - Начать систематически развивать каждую дисциплину
    - Не останавливаться на Prompt Craft, даже если вы в ней уже хороши
    - Понять, что **провал на более высоком уровне имеет более серьезные последствия**:
    - Плохой промпт — потерянное утро
    - Плохой context/intent engineering — проблемы для всей команды/организации
    - Плохой specification engineering — системные провалы на уровне компании

    ---

    ### 09:30 — Дисциплина 1: Prompt Craft как базовый уровень

    **Что обсуждалось:**
    Prompt Craft — это **оригинальная навык**:
    - Синхронная, сессионная, индивидуальная
    - Сидишь перед чат-окном, пишешь инструкцию, оцениваешь вывод, итерируешь

    **Ключевые элементы хорошего промпта:**
    1. **Четкие инструкции**
    2. **Релевантные примеры** и контрпримеры
    3. **Подходящие guardrails** (ограничения)
    4. **Явный формат вывода**
    5. **Четкость в разрешении неопределенностей и конфликтов** (чтобы модель не придумывала на лету)

    **Статус в 2026:**
    - Это то, о чем пишут Anthropic, OpenAI, Google
    - Это в тысячах блог-постов и LinkedIn-курсов
    - **Prompt Craft НЕ стал нерелевантным** — он стал **table stakes** (базовым уровнем)

    **Аналогия:**
    > Умение печатать 10 пальцами когда-то было профессиональным дифференциатором. Теперь это просто предполагается. Если вы не можете написать четкий, хорошо структурированный промпт в 2026, вы как человек в 1998, который не мог отправить email.
    **Почему Prompt Craft был всей игрой:**
    Когда AI-взаимодействия были синхронными и сессионными:
    - Ты всегда был рядом с компьютером
    - Ты видел вывод в реальном времени
    - Ты исправлял ошибки сразу
    - Ты давал дополнительный контекст, когда модель спрашивала или когда замечал отклонение от курса

    **Почему эта модель сломалась:**
    Долгоживущие агенты разбивают **каждое допущение** этой модели:
    - Агент работает часами без проверки
    - Вы не можете исправить ошибки в реальном времени
    - Вся коррекция курса должна быть **встроена в спецификацию до начала работы агента**

    **Вывод — что делать, чтобы быть лучшим:**
    - Освоить базовые навыки Prompt Craft — это обязательно
    - Перечитать документацию по промптингу (Anthropic, OpenAI, Google)
    - Пройти интерактивные туториалы (например, на AI Cred)
    - Создать папку с задачами, которые вы делаете регулярно
    - Для каждой задачи написать лучший промпт и сохранить вывод как baseline
    - Пересматривать эти промпты со временем
    - **Но не останавливаться на этом** — понять, что это только первый уровень из четырех

    ---

    ### 12:00 — Дисциплина 2: Context Engineering

    **Что обсуждалось:**

    **Определение:**
    > Набор стратегий для курирования и поддержания оптимального набора токенов во время задачи LLM.
    **Основная идея:**
    - Промпт, который вы пишете — может быть 200 токенов
    - Контекстное окно, в которое он попадает — может быть **1 миллион токенов**
    - Ваши 200 токенов = **0.02%** того, что видит модель
    - Остальные **99.98%** — это context engineering

    **Что включает Context Engineering:**
    - System prompts
    - Tool definitions
    - Retrieved documents
    - Message history
    - Memory systems
    - MCP connections

    **Артефакты Context Engineering:**
    - `claw.md` файлы
    - Agent specifications
    - RAG pipeline design
    - Memory architectures

    **Определяет:**
    - Понимает ли кодинг-агент конвенции вашего проекта
    - Имеет ли исследовательский агент доступ к правильным документам
    - Может ли агент клиентского сервиса извлечь релевантную историю аккаунта

    **Ключевая проблема (из команды Anthropic):**
    > LLM деградируют по мере того, как вы даете им больше информации.
    **Решение:**
    - Включать **только релевантные токены**
    - Проблема не в том, что модели не могут держать токены
    - Проблема в том, что **качество извлечения падает по мере роста контекста**

    **Практическое следствие:**
    > Люди, которые в 10x эффективнее с AI чем их коллеги, пишут НЕ 10x лучшие промпты. Они строят **10x лучшую контекстную инфраструктуру**.
    Их агенты начинают каждую сессию с:
    - Правильными файлами проекта
    - Правильными конвенциями
    - Правильными ограничениями, уже загруженными

    **Результат:**
    Сам промпт может быть относительно простым, потому что **контекст делает тяжелую работу**.

    **Вывод — что делать, чтобы быть лучшим:**
    - Построить личный контекстный слой
    - Написать эквивалент `claw.md` для своей работы (даже если не используете Claude):
    - Ваши цели
    - Ваши ограничения
    - Ваши коммуникационные предпочтения
    - Ваши стандарты качества
    - Институциональный контекст, который новому члену команды потребовалось бы 6 месяцев чтобы впитать
    - Начинать AI-сессии с загрузки этого контекста
    - Разница в качестве вывода должна быть немедленной и очевидной
    - Понять, что **контекст важнее самого промпта**

    ---

    ### 15:20 — Дисциплина 3: Intent Engineering

    **Что обсуждалось:**

    **Определение:**
    > Практика кодирования организационных целей, ценностей, иерархий компромиссов, границ принятия решений в инфраструктуру, против которой могут действовать агенты.
    **Разница от Context Engineering:**
    - **Context engineering** говорит агентам **что знать**
    - **Intent engineering** говорит агентам **чего хотеть**

    **Метафора:**
    > Intent engineering находится над context engineering так же, как стратегия находится над тактикой.
    **Возможные сценарии:**
    - ✅ Можно иметь идеальный контекст и ужасное выравнивание намерений
    - ❌ Нельзя иметь хорошее выравнивание намерений без хорошего контекста (потому что агенту нужна информация для действия согласно намерениям)

    **Proof case — история Klarna:**
    - AI-агент Klarna обработал **2.3 миллиона разговоров с клиентами** в первый месяц
    - Агент оптимизировался на **неправильную вещь**
    - Он **сократил время разрешения**, но НЕ оптимизировал **удовлетворенность клиентов**
    - Результат: Klarna попала в серьезные проблемы
    - Пришлось заново нанять множество человеческих агентов
    - До сих пор имеют дело с последствиями доверия клиентов

    **Почему это произошло:**
    Плохой Intent Engineering — не было четко определено, что агент должен оптимизировать удовлетворенность клиентов, а не только скорость.

    **Нарастание серьезности провалов:**
    - **Prompt Craft провал:** Потерянное утро (индивидуальный масштаб)
    - **Context Engineering провал:** Проблемы для команды/отдела
    - **Intent Engineering провал:** Проблемы для всей компании, репутационный урон, финансовые потери

    **Вывод — что делать, чтобы быть лучшим:**
    - Четко определить **что именно** должен оптимизировать агент
    - Не предполагать, что "здравый смысл" очевиден для AI
    - Кодировать фреймворки принятия решений вашей команды/организации
    - Для каждой категории работы определить:
    - Что "достаточно хорошо"
    - Что эскалируется AI vs что AI может решить автономно
    - Записать это, структурировать, сделать доступным для агентов
    - На организационном уровне: создать роли/команды, ответственные за Intent Engineering
    - Понять разницу между тактикой (context) и стратегией (intent)

    ---

    ### 17:45 — Дисциплина 4: Specification Engineering

    **Что обсуждалось:**

    **Определение:**
    > Практика написания документов по всей вашей организации, которые автономные агенты могут выполнять в течение продолжительных временных горизонтов без вмешательства человека.
    **Масштаб:**
    - Это уровень **выше всего остального**
    - Первые три уровня фокусировались на том, как вы готовите работу **напрямую для агента**
    - Specification Engineering — это мышление о **всем информационном корпусе вашей организации** как agent-fungible, agent-readable

    **Ключевая идея:**
    Все, что вы пишете, должно быть чем-то, что агент может прочитать и что-то с этим сделать.

    **Характеристики спецификаций:**
    - **Полные** (complete)
    - **Структурированные** (structured)
    - **Внутренне согласованные** (internally consistent)
    - Описывают, каким **должен быть вывод** для данной задачи
    - Определяют, как **измеряется качество**

    **Спецификации — это образ мышления:**
    Вы приносите его к своим документам, что позволяет применять агентов к большим участкам текущего контекста компании с уверенностью, что то, что агент читает, будет релевантным.

    **Пример из Anthropic (Opus 4.5):**
    Команда пыталась построить production-quality web app, но:
    - Если дать агенту только high-level промпт типа "build a clone of claw.ai"
    - Агент пытается сделать слишком много сразу
    - Заканчивается контекст mid-implementation
    - Следующая сессия гадает, что произошло

    **Решение — НЕ лучшая модель, а Specification Engineering:**
    Паттерн, где:
    1. **Начальный laser agent** настраивает окружение
    2. **Progress log** документирует что сделано
    3. **Coding agent** делает инкрементальный прогресс против структурированного плана каждую сессию

    Спецификация стала **scaffolding** (леса), который позволил множественным агентам производить согласованный вывод **в течение дней**.

    **Сдвиг от промпта к спецификации:**
    Это зеркало перехода, который произошел в человеческом инжиниринге десятилетия назад:
    - Когда строишь что-то маленькое → **вербальные инструкции работают**
    - Когда строишь что-то большое, требующее команду или множественные сессии → **нужны blueprints (чертежи)**

    **Фрактальная природа Specification Engineering:**

    **Уровень организации:**
    - Корпоративная стратегия — это спецификация
    - Продуктовая стратегия — это спецификация
    - OKRs — это спецификация
    - Все становится спецификацией, которую может использовать ваш агент

    **Уровень индивидуального агента:**
    - Какой лог у агента?
    - Как мы назначаем задачи в этом агентском билде?
    - Как мы обеспечиваем, что у агента есть четко определенный список требований?

    **Взаимодействие с другими дисциплинами:**
    - Хорошая spec → чище контекстное окно
    - Хороший task log → меньше конфликтов Intent Engineering
    - Меньше раздувания плохим контекстом
    - Все дисциплины начинают взаимодействовать

    **Наивысший уровень:**
    > Думать о спецификации как о том, **как ваша организация ведет бизнес**. Вы специфицируете желаемые выводы. Агент делает работу. Выводы производятся.
    Это наивысший уровень описания того, как будет выглядеть бизнес в следующие пару лет.

    **Вывод — что делать, чтобы быть лучшим:**
    - Начать думать о каждом документе в организации как о спецификации для агента
    - Практиковать написание спецификаций для реальных проектов
    - Для одночеловеческого бизнеса: конвертировать Notion в agent-readable формат
    - Для больших компаний: начать программу конвертации SharePoint/документов в agent-readable спецификации
    - Понять, что ваша org — это система бизнес-процессов, и эти процессы должны быть agent-readable и specifiable
    - Создать роли/команды, ответственные за Specification Engineering на уровне организации
    - Понять, что качественная спецификация определяет **потолок качества** всей работы агента

    ---

    ### 22:30 — Почему долгоживущие агенты разбивают синхронные допущения

    **Что обсуждалось:**

    **Старая ментальная модель (2025):**
    Промптинг = "хорошие инструкции для AI"

    **Почему эта модель проваливается:**
    Она предполагает **синхронное взаимодействие**:
    - Вы всегда за компьютером
    - Вы видите вывод в реальном времени
    - Вы исправляете ошибки сразу
    - Вы даете дополнительный контекст, когда модель спрашивает
    - Вы замечаете отклонение от курса и корректируете

    **Что изменилось:**
    Долгоживущие агенты разбивают **каждое допущение** этой модели:
    - Агенты работают часами/днями **без проверки**
    - Вы не можете видеть вывод в реальном времени
    - Вы не можете корректировать курс на лету

    **Структурная уязвимость:**
    Если вы полагались на допущения синхронного промптинга, у вас есть **структурная уязвимость** в том, как вы думаете об AI.

    **Новое требование:**
    Вы должны думать об AI так, будто **ваш надзор в реальном времени встроен в спецификацию до того, как агент начинает работать**.

    **Архитектура Planner-Worker:**
    Доминирует в production agent deployments:
    1. **Способная модель планирует работу:**
    - Декомпозирует в подзадачи
    - Определяет критерии приемки
    - Назначает работу моделям
    2. **Более дешевые, быстрые модели делают работу**

    **Ключевое правило:**
    > Фаза планирования (= фаза спецификации) определяет **потолок качества**.
    **Последствие:**
    Выполнение без этапа спецификации производит сломанную работу и требует обширных человеческих доработок, чтобы иметь вообще какую-то ценность.

    **Сдвиг в узком месте навыков:**

    **Real-time промптинг награждает:**
    - Вербальную беглость
    - Быструю итерацию
    - Хороший глаз на качество вывода

    **Specification engineering награждает:**
    - Полноту мышления
    - Предвосхищение edge cases (граничных случаев)
    - Четкую артикуляцию критериев приемки
    - Способность декомпозировать сложные результаты в независимо выполняемые компоненты

    **Важное замечание:**
    Разные люди хороши в этих вещах по-разному. Некоторые люди:
    - Естественно исключительны в синхронном промптинге, но будут бороться со specification работой
    - Посредственны в чат-взаимодействии, но могут быть отличными spec engineers

    **Вывод — что делать, чтобы быть лучшим:**
    - Не толерировать свою естественную склонность как потолок
    - Рассматривать specification engineering как **обучаемую навык**
    - Осознанно развивать способность к:
    - Полноте мышления
    - Предвосхищению edge cases
    - Артикуляции критериев приемки
    - Декомпозиции сложных задач
    - Понять, что ваша ценность как работника смещается от способности быстро итерировать к способности **думать полно и структурированно**

    ---

    ### 25:00 — Пять примитивов Specification Engineering

    **Что обсуждалось:**

    Specification Engineering можно разбить на **5 обучаемых примитивов**:

    #### Примитив 1: Self-Contained Problem Statements (Самодостаточные формулировки проблем)

    **Определение (от Toby):**
    > Можете ли вы сформулировать проблему с достаточным контекстом, чтобы задача была правдоподобно решаемой без того, чтобы агент шел за дополнительной информацией?
    **Дисциплина самодостаточности:**
    - Заставляет вас быть четким
    - Выявляет скрытые допущения
    - Заставляет артикулировать ограничения, которые вы обычно оставляете неявными (потому что доверяете человеку на другом конце заполнить пробелы)

    **Проблема с AI:**
    AI не заполняет пробелы надежно. Он заполняет их **статистической правдоподобностью** = он угадывает способами, которые часто **тонко неправильны**.

    **Упражнение для тренировки:**
    1. Возьмите запрос, который вы обычно делаете разговорно: "Update the dashboard to show Q3 numbers"
    2. Перепишите его, как будто получатель:
    - Никогда не видел ваш dashboard
    - Не знает, что означает Q3 в контексте вашей организации
    - Не знает, какую базу данных запрашивать
    - Не имеет доступа к информации кроме той, что вы включили

    Это уровень самодостаточности, к которому вы должны стремиться.

    #### Примитив 2: Acceptance Criteria (Критерии приемки)

    **Проблема:**
    Если вы не можете описать, как выглядит "done", агент не может знать, когда остановиться.

    **Точнее:**
    Агент остановится в точке, где его внутренние эвристики говорят, что задача завершена, что может **не иметь никакого отношения** к тому, что вам нужно.

    **Почему "80% проблема" — это большая проблема:**
    Спецификация говорила "build a login page", когда должна была говорить:

    > Build a login page that handles:
    > - Email & passwords
    > - Social OAuth via Google and GitHub
    > - Progressive disclosure of 2FA
    > - Session persistence for 30 days
    > - Rate limiting after 5 failed attempts
    **Упражнение для тренировки:**
    Для каждой задачи, которую вы делегируете, напишите **три предложения**, которые независимый наблюдатель мог бы использовать для верификации вывода **без вопросов к вам вообще**.

    **Если вы не можете написать эти предложения:**
    Вы вероятно **не понимаете задачу достаточно хорошо**, чтобы дать ее агенту.

    **Личный опыт автора:**
    > У меня было такое, когда я в разговоре с AI-агентом осознал, что я не знаю достаточно, чтобы делегировать задачу, и мне нужно вернуться позже. Это нормально. Хорошо осознать это **до** того, как вы назначите работу.
    #### Примитив 3: Constraint Architecture (Архитектура ограничений)

    **Четыре категории:**
    1. **Musts** — Что агент должен сделать
    2. **Must-nots** — Что агент не может делать
    3. **Preferences** — Что агент должен предпочитать, когда существует несколько валидных подходов
    4. **Escalation triggers** — Что агент должен эскалировать вместо автономного решения

    Эти четыре категории формируют **constraint architecture**, которая превращает свободную спецификацию в очень надежную.

    **Паттерн `claw.md`:**
    Практическая реализация constraint architecture в кодинговом сообществе.

    **Лучшие `claw.md` файлы:**
    - НЕ длинные списки правил
    - Сжатые, чрезвычайно высокосигнальные документы ограничений
    - Примеры:
    - Use these build commands
    - Follow these code conventions
    - Run these tests before marking a task complete
    - Never modify these files without explicit instructions

    **Консенсус сообщества:**
    > Каждая строка в `claw.md` должна зарабатывать свое место. Если вы спрашиваете "приведет ли удаление этой строки к ошибкам AI?" и ответ "нет, не приведет" — убейте строку.
    **Упражнение для тренировки:**
    Перед делегированием задачи напишите вниз, что **умный, благонамеренный человек мог бы сделать, что технически удовлетворило бы запрос, но произвело бы неправильный результат**.

    Эти failure modes становятся вашей constraint architecture. Закодируйте их.

    #### Примитив 4: Decomposition (Декомпозиция)

    **Принцип:**
    Большие задачи нужно разбивать на компоненты, которые могут быть:
    - Выполнены независимо
    - Протестированы независимо
    - Интегрированы предсказуемо

    **Это старейший урок software engineering:**
    Модульность — но применяется к делегированию задач AI.

    **Пример из Anthropic (долгоживущий agent harness):**
    Разбивает каждый сложный проект на:
    1. **Environment setup phase** (фаза настройки окружения)
    2. **Progress documentation phase** (фаза документирования прогресса)
    3. **Incremental coding session** (инкрементальная кодинговая сессия)

    Каждая фаза — независимо верифицируемая.

    **Аналогичная декомпозиция в не-кодинге:**
    Marketing content audit требует той же декомпозиции:
    1. Quality scoring
    2. Gap analysis
    3. Recommendation generation
    И т.д.

    **Упражнение для тренировки:**
    Возьмите любой проект, который вы оцениваете в несколько дней работы, и декомпозируйте в подзадачи, которые:
    - Каждая занимает **менее 2 часов**
    - Имеют четкие input-output границы
    - Могут быть верифицированы независимо от других задач

    Это гранулярность, на которой агенты работают лучше всего.

    **Важное уточнение для 2026:**
    Вы **НЕ должны** пре-специфицировать все эти 2-часовые задачи при написании промпта.

    **Но вы должны:**
    - Понимать, какие все эти задачи
    - Понимать, как описать для planner agent, как выглядит "done"
    - Понимать, как выглядят декомпозируемые части

    **Ваша работа в 2026:**
    НЕ вручную писать подзадачи для агента.

    **Ваша работа:**
    Предоставить **break patterns** (паттерны разбиения), которые planner agent может использовать для разбиения большой работы в надежном, выполняемом виде.

    Это уровень абстракции **даже выше** декомпозиции.

    #### Примитив 5: Evaluation Design (Дизайн оценки)

    **Критичность:**
    - Не только на индивидуальном уровне
    - На уровне организации
    - Организации должны думать о каждом уровне AI deployment в терминах eval

    **Главный вопрос:**
    Как вы знаете, что вывод хороший?

    **НЕ:**
    "Does it look reasonable?" (так оценивает вывод AI большинство людей)

    **А:**
    Можете ли вы доказать **измеримо, последовательно**, что это хорошо?

    **Метафора:**
    - Prompt craft — это искусство **input**
    - Evaluation design — это искусство знания, **сработал ли этот input**

    **Критичность в мире долгоживущих агентов:**
    Eval design — это **единственная вещь**, стоящая между:
    - ❌ AI-генерированным выводом, который я не могу использовать
    - ✅ AI-генерированным выводом, который мы можем использовать as-is

    **Упражнение для тренировки:**
    Для каждой повторяющейся AI-задачи в вашем мире:
    1. **Постройте eval**
    2. **Постройте 3-5 тест-кейсов** с известными хорошими выводами
    3. **Запускайте их периодически**, особенно после обновлений модели

    **Что это дает:**
    - Ловит регрессии
    - Строит вашу интуицию для того, где модели проваливаются
    - Создает институциональное знание о том, как выглядит "хорошо" для ваших конкретных use cases, вашей команды, вас, вашей организации

    **Вывод:**
    Нужно делать это **систематически**.

    ---

    ### 30:15 — Самодостаточные формулировки проблем и критерии приемки

    **Что обсуждалось:**
    (Детально покрыто в разделе "Пять примитивов" выше)

    **Дополнительный акцент:**

    **Self-Contained Problem Statements:**
    Это не просто "предоставить контекст". Это **дисциплина полноты**.

    **Вопрос для самопроверки:**
    > Если бы этот запрос попал к человеку, который никогда не работал в моей компании, не знает наших инструментов, процессов, жаргона — мог бы он выполнить задачу с только этой информацией?
    **Acceptance Criteria:**
    Не просто "список требований". Это **верифицируемые утверждения** о том, что означает завершение.

    **Тест:**
    Независимый наблюдатель с нулевым контекстом должен быть способен взять ваши критерии приемки и сказать "да" или "нет" — задача выполнена?

    **Вывод — что делать, чтобы быть лучшим:**
    - Практиковать написание самодостаточных формулировок ежедневно
    - Для каждого запроса, который вы делаете (AI или человеку), спрашивать: "Включил ли я ВСЁ необходимое?"
    - Выявлять неявные допущения и делать их явными
    - Писать верифицируемые критерии приемки для каждой задачи
    - Проверять: может ли независимый наблюдатель оценить завершение без вопросов к вам?

    ---

    ### 33:00 — Архитектура ограничений и декомпозиция

    **Что обсуждалось:**
    (Детально покрыто в разделе "Пять примитивов" выше)

    **Дополнительный акцент:**

    **Constraint Architecture:**
    Это не просто "правила". Это **структурированная система границ**, которая направляет автономное принятие решений.

    **Четыре типа:**
    1. **Что ДОЛЖНО быть сделано** (non-negotiable requirements)
    2. **Что НЕ ДОЛЖНО быть сделано** (forbidden actions)
    3. **Что ПРЕДПОЧТИТЕЛЬНО** (guidance when multiple valid paths exist)
    4. **Что ЭСКАЛИРУЕТСЯ** (decisions that require human judgment)

    **Decomposition:**
    Не просто "разбить на части". Это создание **независимо выполняемых, независимо верифицируемых модулей работы**.

    **Гранулярность в 2026:**
    < 2 часа работы на подзадачу = sweet spot для agent execution.

    **Эволюция навыка:**
    - **2025:** Вручную разбивать задачи на подзадачи для агента
    - **2026:** Предоставлять planner agent **паттерны разбиения**, которые он может применить сам

    **Вывод — что делать, чтобы быть лучшим:**
    - Создать `claw.md` или эквивалент для ваших проектов
    - Для каждого ограничения спросить: "Приведет ли удаление этого к ошибкам?" — если нет, удалить
    - Практиковать декомпозицию больших задач в 2-часовые модули
    - Документировать **паттерны разбиения**, а не конкретные подзадачи
    - Понять разницу между "вот 50 подзадач" (2025) и "вот как разбить любую большую задачу этого типа на подзадачи" (2026)

    ---

    ### 36:20 — С чего начать: прогрессия, которая строится сама на себе

    **Что обсуждалось:**

    **Порядок важен:**
    Четыре дисциплины представлены в порядке по причине. Это **стек**, где каждый уровень делает возможными уровни выше.

    **Прогрессия обучения:**

    #### Шаг 1: Закрыть пробел в Prompt Craft

    **Почему начать здесь:**
    Большинство людей **хуже в базовом промптинге, чем они думают**.

    **Действия:**
    1. **Перечитать документацию по промптингу:**
    - Anthropic prompting guide
    - OpenAI best practices
    - Google Gemini prompting
    - Статьи на Substack автора

    2. **Пройти интерактивные туториалы:**
    - AI Cred (чтобы увидеть, где вы на промптинге)
    - Другие практические платформы

    3. **Построить baseline:**
    - Создать папку задач, которые вы делаете регулярно
    - Для каждой написать ваш лучший промпт
    - Сохранить выводы как baseline
    - Пересматривать со временем

    **Цель:**
    Принять Prompt Craft серьезно как фундамент.

    #### Шаг 2: Построить личный контекстный слой

    **После того как:**
    Вы чувствуете, что начинаете разбираться в Prompt Craft.

    **Действия:**
    Написать эквивалент `claw.md` для вашей работы (не важно, используете ли вы Claude):

    **Включить:**
    - Ваши цели
    - Ваши ограничения
    - Ваши коммуникационные предпочтения
    - Ваши стандарты качества
    - Институциональный контекст, который новому члену команды потребовалось бы **6 месяцев чтобы впитать**

    **Использование:**
    Начинать AI-сессии с загрузки этого контекста.

    **Ожидаемый результат:**
    Разница в качестве вывода должна быть **немедленной и очевидной**.

    #### Шаг 3: Практиковать Specification Engineering

    **Действия:**
    Взять **реальный проект** (не игрушечную проблему) и написать спецификацию для него **до** прикосновения к AI.

    **Включить:**
    - Self-contained problem statement
    - Acceptance criteria
    - Constraint architecture
    - Decomposition
    - Evaluation design

    **Передать спецификацию агенту и посмотреть, что вернется.**

    **Цель:**
    Научиться **думать в спецификациях**, а не в разговорах.

    #### Шаг 4: Перейти к Intent Infrastructure

    **Контекст:**
    Это **организационный слой**.

    **Если вы управляете людьми или системами:**
    1. Кодировать фреймворки принятия решений, которые ваша команда использует неявно
    2. Определить совместно:
    - Что "достаточно хорошо" для каждой категории работы
    - Что эскалируется AI vs что AI может решить
    3. Записать, структурировать, сделать доступным для агентов

    **Если вы individual contributor:**
    1. Кодировать фреймворки принятия решений, которые **вы** понимаете
    2. Быть **чемпионом**, который продвигает это на организационном уровне
    3. Говорить на языке "построения intent infrastructure" вместо абстрактного "adoption AI"

    #### Шаг 5 (для организаций): Каждый документ = спецификация для агента

    **Перспектива:**
    Ваша организация — это система бизнес-процессов (даже если вы команда из одного).

    **Действия:**
    Начать думать о каждом документе, который вы трогаете, как о спецификации, которую агенту нужно будет прочитать и действовать против.

    **Downstream следствия:**
    Это имеет некоторые из последующих импликаций, о которых говорил Toby:
    > Много организационной политики — это просто плохой context engineering на уровне организации.
    **Практика лучшего specification engineering:**
    - Выявляет неявные допущения, о которых мы политизируем внутри организаций
    - Делает их agent-readable
    - Делает их fungible (взаимозаменяемыми)
    - Начинаем иметь меньше проблем

    **Вывод — что делать, чтобы быть лучшим:**
    - Следовать прогрессии **в порядке** — не пропускать шаги
    - Понять, что это **стек**, а не лестница (вы не можете отказаться от нижних ступеней)
    - Инвестировать время в каждую дисциплину
    - Для организаций: создать роли/команды, ответственные за каждую дисциплину
    - Быть терпеливым — это фундаментальный сдвиг навыков, не быстрый хак

    ---

    ## 🎯 Четыре ключевые темы: Что делаем | Что НЕ делаем

    ### Тема 1: Почему prompt craft стал table stakes, а specification engineering определяет потолок качества

    #### ✅ ЧТО ДЕЛАЕМ:

    1. **Признаем базовый уровень:**
    - Освоить Prompt Craft как обязательный фундамент
    - Относиться к нему как к "умению печатать 10 пальцами" — необходимо, но не дифференциатор

    2. **Инвестируем в specification:**
    - Тратить значительное время на написание полных спецификаций **до** делегирования работы
    - Думать в терминах "blueprints" для агентов, как инженеры думают о чертежах

    3. **Понимаем новую динамику:**
    - Specification определяет **потолок качества** всей работы агента
    - Плохая spec = системный провал, даже с хорошей моделью
    - Хорошая spec + посредственная модель > плохая spec + лучшая модель

    4. **Переориентируем метрики:**
    - Успех = количество завершенных задач **без доработок**
    - Не скорость одной итерации, а throughput законченной работы

    #### ❌ ЧТО НЕ ДЕЛАЕМ:

    1. **Не останавливаемся на Prompt Craft:**
    - Не думаем, что хорошие навыки промптинга в чате = готовность к агентам 2026
    - Не игнорируем необходимость учиться specification engineering

    2. **Не полагаемся на real-time коррекцию:**
    - Не ожидаем, что сможем "исправить позже"
    - Не предполагаем, что агент "спросит, если что-то непонятно"

    3. **Не путаем промпт со спецификацией:**
    - Не даем high-level инструкции типа "build a clone of X" и ожидаем хорошего результата
    - Не экономим время на написании spec — это ложная экономия

    4. **Не недооцениваем сдвиг:**
    - Не относимся к specification engineering как к "улучшенному промптингу"
    - Не пропускаем этот уровень, думая что можно обойтись только context engineering

    ---

    ### Тема 2: Как дисциплина контекст-инжиниринга Toby Lütke делает его emails более сжатыми и меморандумы лучше

    #### ✅ ЧТО ДЕЛАЕМ:

    1. **Практикуем самодостаточность:**
    - Формулируем каждую проблему с **полным контекстом**
    - Спрашиваем: "Может ли получатель решить это без дополнительной информации?"

    2. **Выявляем скрытые допущения:**
    - Идентифицируем неявный контекст, на который мы полагаемся
    - Делаем его явным в коммуникации

    3. **Строим личную контекстную инфраструктуру:**
    - Создаем `claw.md`-эквивалент с нашими:
    - Целями
    - Ограничениями
    - Предпочтениями
    - Стандартами качества
    - Институциональным знанием

    4. **Применяем к человеческой коммуникации:**
    - Понимаем, что навык "хорошего input для AI" = навык "хорошей коммуникации с людьми"
    - Пишем emails и мемо с той же полнотой контекста

    5. **Решаем политику через контекст:**
    - Рассматриваем организационные конфликты как **проблемы контекста**, а не политики
    - Документируем и выравниваем невысказанные допущения

    #### ❌ ЧТО НЕ ДЕЛАЕМ:

    1. **Не полагаемся на "общий контекст":**
    - Не предполагаем, что "они знают, что я имею в виду"
    - Не оставляем критический контекст неявным

    2. **Не путаем краткость с неполнотой:**
    - Краткость Toby = сжатая, но **полная** информация
    - Не краткость за счет пропуска критического контекста

    3. **Не игнорируем человеческий аспект:**
    - Не думаем, что context engineering — только для AI
    - Не упускаем возможность улучшить человеко-человеческую коммуникацию

    4. **Не толерируем небрежность:**
    - Не оправдываем плохую коммуникацию "мы же люди, мы понимаем друг друга"
    - Не позволяем "политике" быть маскировкой для невыраженных допущений

    ---

    ### Тема 3: Как выглядят пять примитивов specification engineering на практике

    #### ✅ ЧТО ДЕЛАЕМ:

    **Примитив 1 — Self-Contained Problem Statements:**
    - Пишем запросы так, будто получатель **никогда не видел наш проект**
    - Включаем все определения, контекст, ограничения
    - Тест: "Может ли незнакомец выполнить это с только этой информацией?"

    **Примитив 2 — Acceptance Criteria:**
    - Пишем 3-5 верифицируемых утверждений о "done"
    - Делаем их измеримыми: "независимый наблюдатель может сказать да/нет"
    - Если не можем написать критерии → не понимаем задачу достаточно хорошо

    **Примитив 3 — Constraint Architecture:**
    - Определяем все четыре категории:
    - **Musts:** Что должно быть сделано
    - **Must-nots:** Что запрещено
    - **Preferences:** Что предпочтительно
    - **Escalations:** Что требует человеческого решения
    - Держим constraint architecture сжатой и высокосигнальной
    - Каждое ограничение должно "зарабатывать свое место"

    **Примитив 4 — Decomposition:**
    - Разбиваем большие задачи в модули **< 2 часов** каждый
    - Обеспечиваем независимые input-output границы
    - Делаем каждый модуль независимо верифицируемым
    - Для 2026: документируем **паттерны разбиения**, не конкретные подзадачи

    **Примитив 5 — Evaluation Design:**
    - Строим eval для каждой повторяющейся AI-задачи
    - Создаем 3-5 тест-кейсов с известными хорошими выводами
    - Запускаем периодически, особенно после model updates
    - Используем для построения институционального знания о "хорошо"

    #### ❌ ЧТО НЕ ДЕЛАЕМ:

    **Примитив 1:**
    - Не оставляем определения неявными
    - Не полагаемся на "они знают наш жаргон/процессы"
    - Не пишем "update the dashboard" без полного контекста

    **Примитив 2:**
    - Не используем расплывчатые критерии типа "make it good"
    - Не предполагаем, что "80% правильно" = успех
    - Не делегируем задачу, для которой не можем написать acceptance criteria

    **Примитив 3:**
    - Не создаем длинные списки правил ради правил
    - Не держим ограничения, которые не предотвращают реальные провалы
    - Не смешиваем все четыре типа ограничений в одну кучу

    **Примитив 4:**
    - Не даем агенту гигантскую задачу без разбиения
    - Не создаем зависимые подзадачи, которые нельзя выполнить независимо
    - Не пишем 50 конкретных подзадач вручную (это 2025 подход)

    **Примитив 5:**
    - Не оцениваем вывод только субъективно ("looks reasonable")
    - Не пропускаем построение eval для повторяющихся задач
    - Не игнорируем регрессии после model updates

    ---

    ### Тема 4: Где находится 10x разрыв между людьми, которые видят все четыре слоя, и людьми, практикующими только один

    #### ✅ ЧТО ДЕЛАЕМ:

    1. **Осваиваем все четыре дисциплины:**
    - **Prompt Craft** как фундамент
    - **Context Engineering** как инфраструктуру
    - **Intent Engineering** как стратегию
    - **Specification Engineering** как организационную трансформацию

    2. **Понимаем кумулятивную природу:**
    - Каждый уровень делает возможными уровни выше
    - Нельзя пропустить уровень
    - Провал на более высоком уровне имеет более серьезные последствия

    3. **Строим системно:**
    - Для индивидуального уровня: личная контекстная инфраструктура
    - Для командного уровня: общие intent frameworks
    - Для организационного уровня: agent-readable документация

    4. **Измеряем правильно:**
    - **1x люди:** Измеряют время на итерацию
    - **10x люди:** Измеряют throughput завершенной работы без доработок

    5. **Инвестируем в спецификацию:**
    - **1x:** 2 минуты на промпт, 40 минут на исправления
    - **10x:** 11 минут на спецификацию, 0 минут на исправления, 5x задач до обеда

    #### ❌ ЧТО НЕ ДЕЛАЕМ:

    1. **Не останавливаемся на одном уровне:**
    - Не думаем "я хорош в промптинге, этого достаточно"
    - Не игнорируем уровни выше, потому что они кажутся "слишком абстрактными"

    2. **Не путаем активность с результатом:**
    - Не гордимся "быстрой итерацией" если throughput низкий
    - Не путаем "много чатов с AI" с "много завершенной работы"

    3. **Не пропускаем уровни:**
    - Не прыгаем к Specification Engineering без Context Engineering
    - Не пытаемся делать Intent Engineering без понимания Context

    4. **Не игнорируем системные эффекты:**
    - Не думаем о промптинге только как об индивидуальной навыке
    - Не упускаем организационную трансформацию, которая необходима

    5. **Не толерируем 80% результаты:**
    - **1x люди:** Принимают "80% правильно, я доделаю" как норму
    - **10x люди:** Строят спецификации, которые дают 100% с первого раза

    **Где живет 10x разрыв:**
    - В **качестве спецификации** до начала работы
    - В **полноте контекстной инфраструктуры**
    - В **ясности intent alignment**
    - В **систематическом eval design**

    **Почему разрыв расширяется:**
    - Агенты становятся способнее → хорошие specs дают еще больший результат
    - Плохие specs с более способными агентами = более дорогие провалы
    - Время работы агентов растет → разница между "правильно с первого раза" и "требует доработки" становится критичнее

    ---

    ## 📚 Выжимка по общим историям

    ### История 1: Что надо подтянуть | изучить | понимать, чтобы быть успешным инженером в 2026 году и выжимать из AI-агентов максимум

    #### 🎓 Навыки для освоения:

    **1. Четыре дисциплины промптинга (в порядке):**

    **Уровень 1 — Prompt Craft (Базовый):**
    - Четкие инструкции
    - Релевантные примеры и контр-примеры
    - Guardrails (ограничения)
    - Явный формат вывода
    - Разрешение амбигуитета
    - **Статус:** Table stakes — обязательно, но недостаточно

    **Уровень 2 — Context Engineering (Критичный):**
    - Понимание, что промпт = 0.02%, контекст = 99.98% того, что видит модель
    - Построение контекстной инфраструктуры:
    - System prompts
    - Tool definitions
    - Memory systems
    - RAG pipelines
    - MCP connections
    - Создание личного `claw.md`-эквивалента
    - Понимание компромисса: больше контекста = деградация retrieval quality
    - **Статус:** Где живет текущее конкурентное преимущество

    **Уровень 3 — Intent Engineering (Стратегический):**
    - Кодирование организационных целей и ценностей
    - Определение иерархий компромиссов
    - Установление границ принятия решений
    - Понимание разницы между стратегией (intent) и тактикой (context)
    - Предотвращение сценариев типа Klarna (оптимизация на неправильную метрику)
    - **Статус:** Критично для автономных агентов

    **Уровень 4 — Specification Engineering (Трансформационный):**
    - Написание полных, структурированных, внутренне согласованных спецификаций
    - Пять примитивов:
    1. Self-contained problem statements
    2. Acceptance criteria
    3. Constraint architecture
    4. Decomposition
    5. Evaluation design
    - Мышление об организационной документации как agent-readable
    - **Статус:** Определяет потолок качества в 2026+

    **2. Фундаментальные сдвиги мышления:**

    **От разговора к работнику:**
    - AI — не chat partner, а autonomous worker
    - Думать в терминах долгоживущих задач (часы/дни), не real-time итераций

    **От итерации к спецификации:**
    - Меньше "быстрой коррекции", больше "полного планирования"
    - Инвестировать время в spec, а не в исправления

    **От индивидуального к системному:**
    - Промптинг — не только личная навык
    - Организационная компетенция, требующая инфраструктуры и ролей

    **3. Технические компетенции:**

    **Evaluation Engineering:**
    - Построение тест-кейсов для AI-задач
    - Измеримые метрики качества
    - Систематическое тестирование при model updates

    **Decomposition:**
    - Разбиение сложных задач в модули < 2 часов
    - Создание независимо верифицируемых компонентов
    - Документирование паттернов разбиения (не конкретных подзадач)

    **Constraint Design:**
    - Четыре типа: musts, must-nots, preferences, escalations
    - Высокосигнальные, сжатые ограничения
    - Каждое ограничение должно предотвращать реальный провал

    **4. Мета-навыки:**

    **Полнота мышления:**
    - Антиципация edge cases
    - Выявление скрытых допущений
    - Системное мышление

    **Коммуникационная дисциплина:**
    - Self-contained формулировки
    - Верифицируемые утверждения
    - Ясность в ограничениях и целях

    **Организационная инженерия:**
    - Конвертация неявного знания в явные документы
    - Построение agent-readable инфраструктуры знаний
    - Решение "политики" через контекст-инжиниринг

    #### 📖 Что изучать:

    **Документация провайдеров:**
    - Anthropic: Prompt engineering guide, Context engineering (Sept 2025 piece)
    - OpenAI: Best practices
    - Google: Gemini prompting

    **Практические инструменты:**
    - AI Cred (оценка навыков промптинга)
    - Claude Code, Pi, OpenCode (практика с долгоживущими агентами)
    - Plannotator (plan review и specification engineering)

    **Паттерны и архитектуры:**
    - `claw.md` pattern и community best practices
    - Planner-Worker architecture
    - Progress logging patterns для долгоживущих агентов

    **Организационные фреймворки:**
    - Specification как organizational infrastructure
    - Intent alignment frameworks
    - Eval design для enterprise deployment

    #### 🧠 Что понимать:

    **1. Природа сдвига:**
    - Это не эволюция промптинга — это **четыре новые дисциплины**
    - Каждая требует разных навыков и мышления
    - Кумулятивная природа — нельзя пропускать уровни

    **2. Где находится ценность:**
    - **2025:** В умении быстро итерировать в чате
    - **2026:** В умении писать спецификации, которые дают правильный результат с первого раза
    - **Будущее:** В построении agent-readable organizational infrastructure

    **3. Асимметрия последствий:**
    - Провал на Prompt Craft = потерянное утро
    - Провал на Context/Intent = проблемы для команды
    - Провал на Specification = системные провалы компании
    - **Риски растут, но и ценность навыков растет**

    **4. Человеческое измерение:**
    - Навыки промптинга = навыки коммуникации
    - Улучшение промптинга улучшает human-to-human коммуникацию
    - Организационная "политика" часто = плохой контекст-инжиниринг

    ---

    ### История 2: Чем отличаются подход 2025 года и 2026 года

    #### 🔄 Фундаментальное изменение парадигмы:

    **2025: Модель чат-партнера**
    - AI как собеседник в реальном времени
    - Синхронное взаимодействие
    - Человек как активный участник на каждом шаге

    **2026: Модель автономного работника**
    - AI как работник, выполняющий долгоживущие задачи
    - Асинхронное делегирование
    - Человек предоставляет полную спецификацию заранее

    #### ⚠️ Что инженеры делают не так (ошибки 2025 подхода):

    **Ошибка 1: Полагаться на real-time коррекцию**

    **2025 подход:**
    - Отправить промпт
    - Посмотреть результат
    - Заметить ошибки
    - Исправить в следующем сообщении
    - Итерировать в реальном времени

    **Почему это не работает в 2026:**
    - Агенты работают часами/днями без проверки
    - Вы не можете "поймать ошибку в реальном времени"
    - К моменту, когда вы видите результат, агент уже потратил часы на неправильное направление

    **Правильный подход:**
    Вся коррекция курса должна быть **встроена в спецификацию до начала работы**.

    ---

    **Ошибка 2: Недостаточная инвестиция в промпт**

    **2025 подход:**
    - 2 минуты на промпт
    - 40 минут на исправление результата
    - Считать это "экономией времени" (было бы 3 часа вручную)

    **2026 подход:**
    - 11 минут на написание полной спецификации
    - 0 минут на исправление
    - 5x задач выполнено до обеда

    **Почему это ошибка:**
    Экономия времени на спецификации = **ложная экономия**.
    - Вы экономите 9 минут на промпте
    - Теряете 40 минут на исправлениях
    - Получаете 1 задачу вместо 5

    **Математика:**
    - **2025:** 2 мин промпт + 40 мин исправления = 42 мин на задачу, 1 задача
    - **2026:** 11 мин spec + 0 мин исправлений = 11 мин на задачу, 5 задач за то же время

    **10x разрыв в throughput.**

    ---

    **Ошибка 3: Путать промпт с контекстом**

    **2025 подход:**
    - Фокус на том, ЧТО написать в чат-окне
    - Промпт = вся игра
    - Игнорирование 99.98% того, что видит модель (контекст)

    **Реальность 2026:**
    - Ваш промпт: 200 токенов (0.02%)
    - Контекстное окно: 1M токенов (99.98%)
    - **Контекст важнее промпта**

    **Последствие:**
    Люди, которые в 10x эффективнее, НЕ пишут 10x лучшие промпты.
    Они строят **10x лучшую контекстную инфраструктуру**.

    **Что это значит:**
    - Личный `claw.md` с целями, ограничениями, стандартами
    - Project-specific контекст
    - Memory systems
    - RAG pipelines
    - Tool definitions

    ---

    **Ошибка 4: Не определять acceptance criteria**

    **2025 подход:**
    - "Build a login page"
    - Получить что-то "80% правильное"
    - Потратить время на доработку до 100%

    **2026 подход:**
    > Build a login page that handles:
    > - Email & passwords
    > - Social OAuth via Google and GitHub
    > - Progressive disclosure of 2FA
    > - Session persistence for 30 days
    > - Rate limiting after 5 failed attempts
    **Почему это критично:**
    Без acceptance criteria агент останавливается, когда **его эвристики** говорят "done".
    Это может не иметь никакого отношения к тому, что **вам** нужно.

    ---

    **Ошибка 5: Игнорировать constraint architecture**

    **2025 подход:**
    - Дать задачу
    - Надеяться, что "здравый смысл" сработает
    - Удивляться, когда агент делает что-то технически правильное, но неправильное в контексте

    **2026 подход:**
    Определить **четыре типа ограничений**:
    1. **Musts:** Что должно быть сделано
    2. **Must-nots:** Что запрещено
    3. **Preferences:** Что предпочтительно при выборе
    4. **Escalations:** Что требует человеческого решения

    **Пример:**
    Без constraint architecture: "Optimize this code"
    → Агент может переписать все в новую парадигму (технически правильно, контекстуально катастрофично)

    С constraint architecture:
    - **Must:** Maintain current API interface
    - **Must-not:** Change database schema
    - **Preference:** Prefer readability over micro-optimizations
    - **Escalate:** Breaking changes that would require API versioning

    ---

    **Ошибка 6: Не декомпозировать большие задачи**

    **2025 подход:**
    - "Build a complete web app"
    - Агент пытается сделать все сразу
    - Заканчивается контекст mid-implementation
    - Следующая сессия не знает, что было сделано

    **2026 подход:**
    Decomposition в модули < 2 часов:
    1. Environment setup
    2. Database schema
    3. API routes (по одной)
    4. Frontend components (по одному)
    5. Integration
    6. Testing

    Каждый модуль:
    - Независимо выполняем
    - Независимо верифицируем
    - Имеет четкие input-output границы

    ---

    **Ошибка 7: Отсутствие eval design**

    **2025 подход:**
    - Субъективная оценка: "Выглядит неплохо"
    - Нет систематического тестирования
    - Не ловить регрессии при model updates

    **2026 подход:**
    - Для каждой повторяющейся AI-задачи: построить eval
    - 3-5 тест-кейсов с известными хорошими выводами
    - Запуск периодически, особенно после updates
    - Измеримые, последовательные метрики качества

    **Почему это критично:**
    Единственная вещь между "AI-вывод, который я не могу использовать" и "AI-вывод, который можно использовать as-is".

    ---

    #### 🎯 Ключевая ошибка 2025 подхода (суммарно):

    **Фундаментальное заблуждение:**
    > "Промптинг — это навык хорошего разговора с AI в реальном времени."
    **Почему это не работает:**
    Это предполагает **синхронное взаимодействие**:
    - ✅ Вы всегда рядом
    - ✅ Вы видите вывод в реальном времени
    - ✅ Вы можете корректировать курс

    **Реальность 2026:**
    Агенты работают **асинхронно**, часами/днями без проверки.

    **Все допущения синхронности разбиваются:**
    - ❌ Вы не рядом
    - ❌ Вы не видите вывод до завершения
    - ❌ Вы не можете корректировать курс

    **Структурная уязвимость:**
    Если вы полагались на допущения синхронного промптинга, у вас есть **структурная уязвимость** в том, как вы думаете об AI.

    ---

    #### ✅ Правильный подход 2026:

    **Новое мышление:**
    > "Промптинг — это инжиниринг полных спецификаций для автономных работников."
    **Что это означает:**
    1. **Вся информация заранее** (self-contained problem statements)
    2. **Четкие критерии завершения** (acceptance criteria)
    3. **Структурированные ограничения** (constraint architecture)
    4. **Модульная декомпозиция** (< 2 часа на модуль)
    5. **Измеримое качество** (eval design)

    **Навык смещается:**
    - **От:** Вербальная беглость и быстрая итерация
    - **К:** Полнота мышления и структурированная артикуляция

    **Метрика успеха:**
    - **2025:** Скорость итерации
    - **2026:** Throughput завершенной работы без доработок

    ---

    #### 📊 Почему подходы 2025 года дают меньше эффекта:

    **1. Потолок производительности:**
    - 2025 навыки имеют **ceiling** (потолок)
    - Вы можете стать очень хорошим в real-time промптинге
    - Но максимум = "экономия 50-60% времени на задачу"
    - 2026 навыки = "недельная работа за утро" (10x+)

    **2. Стоимость ошибок растет:**
    - 2025: Ошибка в чате = потеря нескольких минут
    - 2026: Плохая spec для долгоживущего агента = потеря часов/дней работы агента
    - Цена плохого промптинга **экспоненциально выросла**

    **3. Модели обогнали методологию:**
    - Opus 4.6, Gemini 3.1 Pro, GPT 5.3 **могут** работать автономно днями
    - Но большинство людей все еще используют их как chatbots
    - **Неиспользуемая способность** = потерянное преимущество

    **4. Конкурентное давление:**
    - Компании, которые адаптировались к 2026 подходу, уже в production
    - Telus: 13,000 custom AI solutions
    - Zapier: 800+ agents
    - "Если они выпустили press release, они чувствуют себя позади" — реальные лидеры на порядок больше

    **5. Widening gap (расширяющийся разрыв):**
    - 10x разрыв между теми, кто понимает все 4 дисциплины, и теми, кто практикует только Prompt Craft
    - Этот разрыв **расширяется**, не сужается
    - Потому что модели становятся способнее → хорошие specs дают еще больший результат

    ---

    #### 🔑 Ключевые выводы:

    **Что изменилось:**
    - **Не модели стали умнее** (хотя и это тоже)
    - **Модели стали способны работать автономно долго**
    - Это меняет **что значит "хорошо промптить"** на фундаментальном уровне

    **Что требуется:**
    - Не "лучшие промпты"
    - **Другие навыки:** Specification engineering вместо conversational prompting

    **Что на кону:**
    - 2025 подход: Экономия времени (50-60%)
    - 2026 подход: Трансформация производительности (10x+)

    **Временной фактор:**
    - "Если вы промптите как в прошлом месяце, вы уже опоздали"
    - Модели обновляются **каждый месяц**
    - Best practices эволюционируют **быстро**
    - Отставание даже на несколько месяцев = серьезный конкурентный недостаток

    ---

    ## 📌 Финальная мысль

    > Спецификация, сделанная правильно, оказывается просто тем, как **всегда выглядело ясное мышление** — сделанное явным, потому что машины не позволяют нам быть небрежными в этом.
    Это не просто о том, как использовать AI. Это о том, как **думать, коммуникировать и организовывать работу** в мире, где ясность и полнота стали технической необходимостью, а не просто добродетелью.

    ---

    **Автор видео:** Nate
    **Длительность:** 41:11
    **Ключевые слова:** prompt engineering, specification engineering, context engineering, intent engineering, AI agents 2026, autonomous agents, Toby Lütke, Claude Opus 4.6, GPT 5.3, Gemini 3.1 Pro

    ---

    *Саммари создано 28 февраля 2026*