How I AI: как я работаю, учусь и создаю с AI

Конспект открытого вебинара Байрама Аннакова · 30 октября 2026

Основа конспекта: фактическая запись и чат встречи длительностью 1:47:41. Время ниже относится к исходной записи Onsa/Zoom.

Главная идея

Работа с AI состоит не только из удачного запроса. Важно подготовить контекст, получить проверяемый результат, испытать его в реальных условиях, внести поправку и сохранить полезный вывод для следующей похожей задачи.

Контекст → Попытка → Проверка → Исправление → Повторное использование.

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

Что изменилось с января

• Больше Codex и голосового общения, особенно для обучения, написания постов и подготовки занятий.
• Более явная проверка через разные модели и среды их работы, а не только через другую модель.
• Интерактивный HTML как результат работы: его можно открыть, прокликать и комментировать по месту.
• Проверка после выпуска: вернуться к изменению, измерить эффект и решить, оставить его или отключить.
• Накопление полезных поправок в правилах проекта, командах и навыках агента.

В январе уже были голос, контекст, MCP, навыки и проверки через Codex. Изменение состоит в расширении и уточнении практики, а не в первом появлении всех этих инструментов в октябре.

Что действительно показали

Байрам открыл рабочую переписку о сегодняшнем посте про AI и творчество, показал точечные комментарии к артефактам и объяснил проверку навыков в чистой среде. Во время встречи запустился еженедельный сбор источников для NotebookLM; позже был показан получившийся аудиообзор. Также обсуждались измерение эффекта продуктовых изменений, модификации Claude Code, обучение через игры и следующий шаг к постоянно работающему агенту.

Восемь пересекающихся областей

• Учиться: обсуждать непонятное, пробовать объяснение своими словами, строить карту области, просить игру или контрпример.
• Исследовать: собирать источники, уточнять вопрос, сравнивать альтернативы и независимые мнения.
• Измерять: работать с продуктовой аналитикой, проверять необычные цифры и качество самого измерения.
• Создавать: писать посты, готовить занятия, презентации и другие документы.
• Разрабатывать: менять продукт, проводить тесты, проверять работу в браузере и в рабочей системе.
• Вести операционную работу: собирать информацию для финансовых, юридических и административных задач.
• Координировать: готовить встречи, фиксировать решения, связывать работу людей и агентов.
• Улучшать способ работы: исправлять повторяющиеся ошибки, менять навыки, правила и инструменты.

Основная среда

Байрам описал Codex и Claude Code как два основных инструмента. Другие среды, включая Grok, Cursor и инструменты с Gemini, подключаются на отдельных этапах, в частности для критического разбора. Упомянутые 3-4 параллельные сессии в каждом инструменте - оценка самого автора, не измеренная статистика использования.

Что находится за картой

Примеры методов: telegram-post-writer, clean-slate-test, edu-workshop-run, lead-search-review, 2026-coach, eval-hillclimb, команды /weekly-meeting и /after-weekly.

Примеры подключений: Anysite для внешних источников, включая X и YouTube; Onsa Meetings для записей разговоров; инструменты для почты, календаря, аналитики и данных. NotebookLM превращает выбранные источники в удобный для прослушивания обзор. Не каждое подключение является MCP: например, загрузка через yt-dlp и работа через API - другие способы доступа.

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

Модель и harness - два разных выбора · 06:05 и 51:48

Модель - языковая система, которая генерирует ответ. Harness - окружающая ее программная среда: доступные инструменты, управление контекстом, выполнение действий и организация проверки.

Одна модель внутри разных сред может работать по-разному. Поэтому в своем процессе Байрам просит независимый взгляд не только у другой модели, но и через другую рабочую среду. Это не голосование: рецензент должен получить нужный материал, его замечания надо разобрать, а существенные предположения - проверить исполнением.

Подготовить материал и вопрос → проверить доступ рецензента → разобрать замечание → исполнить проверку.

В речи был назван по памяти множитель «в 5 или 7 раз» из обсуждения исследований. В конспекте он не используется как установленный универсальный эффект. Личные наблюдения о глубине поиска разных инструментов также остаются наблюдениями автора.

Как проверять чужой отчет · 32:13

1. Сначала самому просмотреть результат, чтобы понять структуру и заметить странности.
2. Оставить точечные вопросы: какое утверждение проверить, какой источник найти, что требует объяснения.
3. Дать агентам выполнить эти проверки.
4. Перечитать результат с учетом доказательств и только затем сформулировать окончательный отзыв.

Человек отвечает за то, что принес · 42:46

Пример из обсуждения: отчет с конверсией выше 100% нельзя просто переслать со словами «это сделал AI». Нужен человек, который понимает счетчик, знаменатель и ограничения вывода и готов отвечать за результат.

HTML и комментарии по месту · 34:14-39:14

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

На встрече была показана переписка по этой презентации: отмеченные на слайдах вопросы приходили агенту вместе с местом, к которому относилась поправка. В Claude был показан отдельный демонстрационный артефакт и пример комментария «переведи на русский».

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

Еженедельная встреча · 39:14-44:17

Короткая команда /weekly-meeting опирается на предыдущие решения, свежие отчеты и контекст команды. После разговора /after-weekly помогает обработать реальные итоги и обновить рабочую базу знаний.

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

Урок: прежде чем объяснять поведение бизнеса, проверить, что именно и как считает отчет. Необычная цифра - повод исследовать измерение, а не немедленно придумывать убедительную историю.

Публичные объяснения подхода:

https://t.me/ProductsAndStartups/1753

https://t.me/ProductsAndStartups/1862

Чистая среда · 44:17-51:48

На машине автора уже есть библиотеки, глобальные правила и подключения, которых может не быть у другого человека. Поэтому «работает у меня» недостаточно, когда навык или упражнение передают дальше.

В историческом примере AI Sales нужно было получить, среди прочего, файл с вопросами для первого разговора с потенциальным клиентом. Изолированный запуск выполнился быстрее, но не создал обязательный файл.

• scoring-model.md: на машине автора 20 370 байт; в чистой среде 12 254 байта.
• first-call-questions.md: на машине автора 2 929 байт; в чистой среде не создан.
• Время: 337 секунд против 144 секунд. Более быстрый запуск не выполнил обещанный результат.

Инструкция стала явно требовать signals/qualification/first-call-questions.md. Повторная проверка создала файл размером 3 366 байт. Размер подтверждает наличие файла, но не качество вопросов и не результат обучения.

Сохранить проверку и ее запуск

Был создан clean-slate-test, а вызывающий его процесс edu-workshop-run изменен так, чтобы эта проверка не терялась. Смысл правила: чистая копия папки не равна чистой машине.

В другом, более позднем запуске изоляция помогла обнаружить неявную зависимость от jq. Это отдельный случай частичного повторного использования метода.

Рецензент тоже может ошибаться · 57:18

Замечание о возможном неверном размещении файлов надо проверить командой в реальной среде. В сохраненном примере выполненная проверка не подтвердила предполагаемое вложение папки. Независимость рецензента полезна; принятие каждого его предложения без проверки - отдельная ошибка.

Живой пример: пост про AI и творчество · 01:00:18-01:09:50

На встрече главным открытым примером стал сегодняшний пост по мотивам публикации Джеффри Катценберга.

1. Зацепка: статья, собственная мысль, опыт или наблюдение.
2. Агент задает вопросы, чтобы получить личный взгляд автора, а не пересказ новости.
3. Байрам отвечает, преимущественно голосом, уточняет мысль и оставляет комментарии.
4. Когда материала достаточно, появляется первый черновик.
5. Автор корректирует формулировки, выбирает иллюстрацию и проверяет Telegram-черновик перед публикацией.
6. После выхода можно сопоставить прогноз и фактические показатели и решить, что изменить в методе.

В показанном примере первый текстовый черновик оказался близок к нужному, но перед публикацией автор все равно внес собственные изменения. Это не означает, что любой пост получается с одной попытки. Байрам оценил весь процесс примерно в час, с переключениями на другую работу.

Пост из живого примера:

https://t.me/ProductsAndStartups/1874

FDE-Gym: исследование меняет пост · 01:13:22-01:16:53

В другом случае обсуждение публичного задания превратилось в эксперимент. Автор задавал вопросы о подходе, оценке и затратах. Затем пришлось отойти от слишком узкого пересказа кейса и вернуть связь с более широкой серией о мышлении и обучении. Менялась и иллюстрация: ощущение «большого брата» заменили более дружелюбным образом.

https://t.me/ProductsAndStartups/1872

Робототехника и несовпадение с прогнозом

У поста о симуляторе Reachy показатели оказались ниже прогноза: 2 741 просмотр вместо 4 000, 13 пересылок вместо 50 за сопоставленное семидневное окно. Но автор еще до этих результатов ценил то, чему научился в процессе. Поэтому правило не свелось к «писать только то, что набирает охват».

Просмотры не равны уникальным людям. Пересылки могут включать сохранения себе; это не точный счетчик сохранений. Метрика пересылки/просмотры - личный ориентир автора, не универсальная цель.

https://t.me/ProductsAndStartups/1852

Followthrough · 01:16:53-01:22:54

Чем быстрее агенты помогают выпускать изменения, тем легче забыть, ради какого эффекта их сделали. Followthrough сохраняет исходное состояние, ожидаемый результат, срок и способ проверки. Позже нужно вернуться со свежими данными и записать вердикт.

Исходные показатели → ожидание → контрольная точка → измерение → решение.

Затраты: отделить причины

В большом сентябрьском разборе инфраструктуры около $1 734 в месяц были оценкой изменения структурных текущих затрат. Около $326 были связаны со спросом, а около $101 эффекта лимитов не включали в структурную экономию. Это оценка месячного темпа расходов, а не уже наблюденная экономия по полному месячному счету.

В отдельном более позднем примере мониторинга: $2,188 в день до изменения, ожидание около $0,28, наблюдение по завершенным дням $0,087. Снижение на 96% относится к одной позиции счета, не ко всему GCP. Эти исторические значения проверены по материалам кейса; текущий счет не запрашивался заново.

Теневой режим и включение в продакшн

Теневой режим позволяет записать, какое решение приняла бы новая логика, не отдавая это решение пользователю. В кейсе ранней остановки D1 было 31 потенциальное прекращение поиска на 127 вызовов. В 19 из этих 31 вызова поиск затем дал принятые лиды. Это число вызовов, а не количество выброшенных людей: поиск продолжался. D1 отключили; более поздняя проверка показала 0 таких остановок на 112 вызовах.

Другую функцию - раннюю выдачу первого подходящего результата - включили и проверили уже после включения. Доли 43% в shadow и 41% после включения относятся к разным наборам наблюдений, не к рандомизированному сравнению. Медианный выигрыш 12,3 секунды - время от ранней выдачи до конца шага поиска, а не ускорение всего пользовательского запроса.

Урок: не путать публикацию изменения, наблюдение его поведения и подтверждение полезного эффекта.

Голос, игры и контрпримеры · 01:27:55-01:36:27

Голос особенно полезен вне компьютера, на прогулке или пробежке, и когда нужно передать много контекста. В обучении агент может не только объяснить идею, но и помочь придумать маленький эксперимент, контрпример или игровую среду.

• Lean: обсуждение правил и контрпримеров помогало уточнить предположения. Идея превращать бизнес-требования в формальные спецификации обсуждалась как направление исследования. Доказательство в формальной модели само по себе не сертифицирует любую работающую программу.
• Пенсионный фонд: после обсуждения распределения активов Codex создал мини-игру The Mandate с решениями и встроенным помощником. Игра служила способом разобраться; демонстрация интерфейса не является независимой проверкой усвоения.
• NotebookLM: агент собирает источники с высоким, по оценке автора, отношением полезного сигнала к шуму. Аудиообзор служит первым фильтром, после которого отдельные идеи уходят в глубокое изучение или посты.

Во время самого вебинара прошел еженедельный сбор материалов. Персонализация обзора учитывает, что слушатель - практик и преподаватель, какие методы он уже использует и какие учебные решения ему предстоят. NotebookLM использовался раньше; улучшение связано с контекстом слушателя.

https://t.me/ProductsAndStartups/1869

Четыре модификации Claude Code · 01:22:54-01:27:55

• limits-watch: видеть приближение лимита и поддерживать непрерывность работы.
• meeting-wrap: напомнить обработать завершившийся разговор и принять решения по его итогам.
• followthrough-band: напомнить о проверках ожидаемого эффекта прямо в рабочей сессии.
• reflect-mod: предложить сохранить, отредактировать или пропустить полезную поправку, выбрав проектное либо глобальное правило.

Картинки интерфейсов модов в слайдах - примеры из проектов. Байрам не открыл один из приватных рабочих экранов. Не каждое сохраненное правило стоит сохранять навсегда: неправильное предположение тоже может накапливаться и усиливаться.

Постоянно работающий агент · 01:37:57-01:47:30

Текущая проблема автора: много времени уходит на запуск, координацию и проверку других агентов. Следующий шаг для Robin - взять на себя больше этой работы и обращаться к человеку за целями, ограничениями и существенными решениями.

Байрам обозначил желание передать хотя бы половину такой координации, но не сообщил, что эта цель уже достигнута. В ответе Андрею он подчеркнул: пока исследует варианты и не готов назвать один инструмент проверенной лучшей практикой. Аналогия с RTS/StarCraft - способ подумать о карте работ и сигналах внимания, а не доказанный метод повышения производительности.

Что участники собирались попробовать

В чате Андрей отметил игры для понимания предмета, Ксения - followthrough и программный запуск агентов, Александр - процесс написания постов, Артем - подкасты. Это намерения после встречи, не подтвержденные внедрения.

Ирек и Аким поделились собственными наблюдениями о документации, терминальных сессиях и координации. Рекомендации участников не следует читать как проверенные рекомендации Байрама.

Практика после просмотра

Длинного отдельного практического блока с отчетом о выполнении на встрече не было. Байрам предложил выбрать собственную задачу и написать о ней в чат или позже в комментарии.

1. Я хочу регулярно получать какой результат?
2. Какой контекст нужен: документы, данные, предыдущие решения?
3. Как выглядит пригодный результат: файл, отчет, работающий интерфейс?
4. Что надо исполнить или измерить, прежде чем ему доверять?
5. Какую полезную поправку я сохраню и что вызовет ее в следующий раз?

Обещанные материалы

Байрам обещал запись и PDF со ссылками зарегистрировавшимся через Luma по электронной почте, а также запись в канале. Этот конспект не является подтверждением отправки. Публичные сообщения и письма проходят отдельное одобрение автора.

• Workflow - повторяемая последовательность работы от запроса до пригодного результата.
• Агент - программа, которая использует модель и инструменты для выполнения действий.
• Harness - программная среда вокруг модели: инструменты, контекст и управление выполнением.
• Skill - сохраненная инструкция для определенного типа задач, часто с примерами и вспомогательными файлами.
• MCP - способ подключить агенту внешний инструмент или источник через согласованный интерфейс.
• Артефакт - отдельный результат работы, который можно открыть, изучить и исправить: документ, таблица, страница или прототип.
• Inline-комментарий - замечание, привязанное к конкретному месту в результате.
• Контекст - сведения и ограничения, которые агент получает для этой задачи.
• Cross-check - дополнительная проверка результата или утверждения через другой источник, модель или среду.
• Review - разбор результата и замечаний. Не заменяет исполнение теста.
• Clean-slate test - запуск опубликованной инструкции в среде без скрытых удобств машины автора.
• Sandbox / Docker - изолированная среда запуска. Изоляцию надо настроить и проверить; само слово не гарантирует ее.
• API - программный способ вызвать функцию сервиса.
• CLI / headless - работа с программой командами, в том числе без интерактивного чата.
• Shadow mode - новая логика принимает и записывает пробные решения, пока пользователю продолжает служить прежний процесс.
• Rollout / rollback - включение изменения для пользователей / возврат к прежнему поведению.
• Baseline - исходное измерение, с которым сравнивают эффект изменения.
• Prod - рабочая система, которой пользуются реальные пользователи.
• Sunk cost - уже понесенные затраты, которые нельзя вернуть и которые могут мешать отказаться от идеи.
• Socratic method - обучение и уточнение мысли через вопросы и проверку собственных предположений.
• RTS - игра-стратегия в реальном времени; в разговоре это аналогия для видимости работ и распределения внимания.

Личные посты об HTML, комментариях, робототехнике, FDE-Gym и NotebookLM перечислены в соответствующих разделах. Публичные коллекции и инструменты:

https://github.com/BayramAnnakov/systems-thinking-skills

https://github.com/anthropics/knowledge-work-plugins/tree/main/data/skills

https://github.com/BayramAnnakov/ai-personal-os-s3

https://github.com/BayramAnnakov/followthrough

https://github.com/BayramAnnakov/claude-reflect

Личный пост о коучинге и планировании:

https://t.me/ProductsAndStartups/1610

Из чата: пример терминального инструмента участника, не рекомендация по результатам тестирования Байрама:

https://github.com/umputun/agterm

Ссылка Байрама на неинтерактивный запуск Claude Code:

https://code.claude.com/docs/en/headless

Видео, которым Байрам поделился в обсуждении harness:

https://www.youtube.com/watch?v=n9xKblqyQ28

Дополнительное чтение из подготовленных слайдов (не доказательство универсального эффекта личного процесса):

https://openai.com/index/harness-engineering/

https://www.anthropic.com/research/building-effective-agents

https://arxiv.org/abs/2503.13657

Пределы конспекта: личный опыт не является универсальной гарантией. Устные оценки, гипотезы, результаты тестов и работа в продакшне различаются. Имена клиентов, их данные, адреса участников и приватные ссылки в материалы не включены.