ivan-hilckov/part1-video.md

🎬 Часть 1: Разбор видео по таймкодам

Видео: 'Prompting' Just Split Into 4 Skills
Автор: 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 различных дисциплины:

Prompt Craft — базовые навыки промптинга
Context Engineering — курирование токенов в контексте
Intent Engineering — кодирование целей и ценностей
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 — С чего начать: Прогрессия

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

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

Дата: 28 февраля 2026

📊 Часть 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: Ответы на ключевые вопросы

Вопрос 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 примитивов:

Self-contained problem statements
Acceptance criteria
Constraint architecture (musts, must-nots, preferences, escalation)
Decomposition (<2h tasks)
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

Детальное саммари: "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 — это оригинальная навык:

Синхронная, сессионная, индивидуальная
Сидишь перед чат-окном, пишешь инструкцию, оцениваешь вывод, итерируешь

Ключевые элементы хорошего промпта:

Четкие инструкции
Релевантные примеры и контрпримеры
Подходящие guardrails (ограничения)
Явный формат вывода
Четкость в разрешении неопределенностей и конфликтов (чтобы модель не придумывала на лету)

Статус в 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: Паттерн, где:

Начальный laser agent настраивает окружение
Progress log документирует что сделано
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:

Способная модель планирует работу:
- Декомпозирует в подзадачи
- Определяет критерии приемки
- Назначает работу моделям
Более дешевые, быстрые модели делают работу

Ключевое правило:

Фаза планирования (= фаза спецификации) определяет потолок качества.

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

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

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 не заполняет пробелы надежно. Он заполняет их статистической правдоподобностью = он угадывает способами, которые часто тонко неправильны.

Упражнение для тренировки:

Возьмите запрос, который вы обычно делаете разговорно: "Update the dashboard to show Q3 numbers"
Перепишите его, как будто получатель:
- Никогда не видел ваш 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 (Архитектура ограничений)

Четыре категории:

Musts — Что агент должен сделать
Must-nots — Что агент не может делать
Preferences — Что агент должен предпочитать, когда существует несколько валидных подходов
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): Разбивает каждый сложный проект на:

Environment setup phase (фаза настройки окружения)
Progress documentation phase (фаза документирования прогресса)
Incremental coding session (инкрементальная кодинговая сессия)

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

Аналогичная декомпозиция в не-кодинге: Marketing content audit требует той же декомпозиции:

Quality scoring
Gap analysis
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-задачи в вашем мире:

Постройте eval
Постройте 3-5 тест-кейсов с известными хорошими выводами
Запускайте их периодически, особенно после обновлений модели

Что это дает:

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

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

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

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

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

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

Вопрос для самопроверки:

Если бы этот запрос попал к человеку, который никогда не работал в моей компании, не знает наших инструментов, процессов, жаргона — мог бы он выполнить задачу с только этой информацией?

Acceptance Criteria: Не просто "список требований". Это верифицируемые утверждения о том, что означает завершение.

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

Вывод — что делать, чтобы быть лучшим:

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

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

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

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

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

Четыре типа:

Что ДОЛЖНО быть сделано (non-negotiable requirements)
Что НЕ ДОЛЖНО быть сделано (forbidden actions)
Что ПРЕДПОЧТИТЕЛЬНО (guidance when multiple valid paths exist)
Что ЭСКАЛИРУЕТСЯ (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

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

Действия:

Перечитать документацию по промптингу:
- Anthropic prompting guide
- OpenAI best practices
- Google Gemini prompting
- Статьи на Substack автора
Пройти интерактивные туториалы:
- AI Cred (чтобы увидеть, где вы на промптинге)
- Другие практические платформы
Построить 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

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

Если вы управляете людьми или системами:

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

Если вы individual contributor:

Кодировать фреймворки принятия решений, которые вы понимаете
Быть чемпионом, который продвигает это на организационном уровне
Говорить на языке "построения intent infrastructure" вместо абстрактного "adoption AI"

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

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

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

Downstream следствия: Это имеет некоторые из последующих импликаций, о которых говорил Toby:

Много организационной политики — это просто плохой context engineering на уровне организации.

Практика лучшего specification engineering:

Выявляет неявные допущения, о которых мы политизируем внутри организаций
Делает их agent-readable
Делает их fungible (взаимозаменяемыми)
Начинаем иметь меньше проблем

Вывод — что делать, чтобы быть лучшим:

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

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

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

✅ ЧТО ДЕЛАЕМ:

Признаем базовый уровень:
- Освоить Prompt Craft как обязательный фундамент
- Относиться к нему как к "умению печатать 10 пальцами" — необходимо, но не дифференциатор
Инвестируем в specification:
- Тратить значительное время на написание полных спецификаций до делегирования работы
- Думать в терминах "blueprints" для агентов, как инженеры думают о чертежах
Понимаем новую динамику:
- Specification определяет потолок качества всей работы агента
- Плохая spec = системный провал, даже с хорошей моделью
- Хорошая spec + посредственная модель > плохая spec + лучшая модель
Переориентируем метрики:
- Успех = количество завершенных задач без доработок
- Не скорость одной итерации, а throughput законченной работы

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

Не останавливаемся на Prompt Craft:
- Не думаем, что хорошие навыки промптинга в чате = готовность к агентам 2026
- Не игнорируем необходимость учиться specification engineering
Не полагаемся на real-time коррекцию:
- Не ожидаем, что сможем "исправить позже"
- Не предполагаем, что агент "спросит, если что-то непонятно"
Не путаем промпт со спецификацией:
- Не даем high-level инструкции типа "build a clone of X" и ожидаем хорошего результата
- Не экономим время на написании spec — это ложная экономия
Не недооцениваем сдвиг:
- Не относимся к specification engineering как к "улучшенному промптингу"
- Не пропускаем этот уровень, думая что можно обойтись только context engineering

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

✅ ЧТО ДЕЛАЕМ:

Практикуем самодостаточность:
- Формулируем каждую проблему с полным контекстом
- Спрашиваем: "Может ли получатель решить это без дополнительной информации?"
Выявляем скрытые допущения:
- Идентифицируем неявный контекст, на который мы полагаемся
- Делаем его явным в коммуникации
Строим личную контекстную инфраструктуру:
- Создаем claw.md-эквивалент с нашими:
  - Целями
  - Ограничениями
  - Предпочтениями
  - Стандартами качества
  - Институциональным знанием
Применяем к человеческой коммуникации:
- Понимаем, что навык "хорошего input для AI" = навык "хорошей коммуникации с людьми"
- Пишем emails и мемо с той же полнотой контекста
Решаем политику через контекст:
- Рассматриваем организационные конфликты как проблемы контекста, а не политики
- Документируем и выравниваем невысказанные допущения

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

Не полагаемся на "общий контекст":
- Не предполагаем, что "они знают, что я имею в виду"
- Не оставляем критический контекст неявным
Не путаем краткость с неполнотой:
- Краткость Toby = сжатая, но полная информация
- Не краткость за счет пропуска критического контекста
Не игнорируем человеческий аспект:
- Не думаем, что context engineering — только для AI
- Не упускаем возможность улучшить человеко-человеческую коммуникацию
Не толерируем небрежность:
- Не оправдываем плохую коммуникацию "мы же люди, мы понимаем друг друга"
- Не позволяем "политике" быть маскировкой для невыраженных допущений

Тема 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 разрыв между людьми, которые видят все четыре слоя, и людьми, практикующими только один

✅ ЧТО ДЕЛАЕМ:

Осваиваем все четыре дисциплины:
- Prompt Craft как фундамент
- Context Engineering как инфраструктуру
- Intent Engineering как стратегию
- Specification Engineering как организационную трансформацию
Понимаем кумулятивную природу:
- Каждый уровень делает возможными уровни выше
- Нельзя пропустить уровень
- Провал на более высоком уровне имеет более серьезные последствия
Строим системно:
- Для индивидуального уровня: личная контекстная инфраструктура
- Для командного уровня: общие intent frameworks
- Для организационного уровня: agent-readable документация
Измеряем правильно:
- 1x люди: Измеряют время на итерацию
- 10x люди: Измеряют throughput завершенной работы без доработок
Инвестируем в спецификацию:
- 1x: 2 минуты на промпт, 40 минут на исправления
- 10x: 11 минут на спецификацию, 0 минут на исправления, 5x задач до обеда

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

Не останавливаемся на одном уровне:
- Не думаем "я хорош в промптинге, этого достаточно"
- Не игнорируем уровни выше, потому что они кажутся "слишком абстрактными"
Не путаем активность с результатом:
- Не гордимся "быстрой итерацией" если throughput низкий
- Не путаем "много чатов с AI" с "много завершенной работы"
Не пропускаем уровни:
- Не прыгаем к Specification Engineering без Context Engineering
- Не пытаемся делать Intent Engineering без понимания Context
Не игнорируем системные эффекты:
- Не думаем о промптинге только как об индивидуальной навыке
- Не упускаем организационную трансформацию, которая необходима
Не толерируем 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 подход: Определить четыре типа ограничений:

Musts: Что должно быть сделано
Must-nots: Что запрещено
Preferences: Что предпочтительно при выборе
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 часов:

Environment setup
Database schema
API routes (по одной)
Frontend components (по одному)
Integration
Testing

Каждый модуль:

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

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

2025 подход:

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

2026 подход:

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

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

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

Фундаментальное заблуждение:

"Промптинг — это навык хорошего разговора с AI в реальном времени."

Почему это не работает: Это предполагает синхронное взаимодействие:

✅ Вы всегда рядом
✅ Вы видите вывод в реальном времени
✅ Вы можете корректировать курс

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

Все допущения синхронности разбиваются:

❌ Вы не рядом
❌ Вы не видите вывод до завершения
❌ Вы не можете корректировать курс

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

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

Новое мышление:

"Промптинг — это инжиниринг полных спецификаций для автономных работников."

Что это означает:

Вся информация заранее (self-contained problem statements)
Четкие критерии завершения (acceptance criteria)
Структурированные ограничения (constraint architecture)
Модульная декомпозиция (< 2 часа на модуль)
Измеримое качество (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