Коучинг on Михаил Шогин

Три блокера, которые мешают техническому лидеру расти

Mon, 16 Mar 2026 00:00:00 +0000

AI меняет IT быстрее, чем мы успеваем адаптироваться. Роли трансформируются. Навыки, за которые платили вчера, обесцениваются сегодня.

Чтобы сохранить уровень жизни - нужно расти. Но рост упирается не в технологии. Не в стек. Не в сертификаты.

Он упирается в мышление.

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

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

Вот три паттерна, которые я вижу чаще всего. В других. И в себе.

Блокер 1: Защита территории

У каждого лидера есть зона ответственности. И любой вход в нее воспринимается как атака. Это инстинкт - как хищник обходит свои границы.

Как это выглядит

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

На совещании ты начинаешь давить. Не потому что решение плохое - а потому что оно принято без тебя. Формально ты говоришь про качество и процессы. Реально - защищаешь территорию.

Другой пример. Тимлид замечает, что senior в команде начинает брать на себя архитектурные вопросы. Вместо того чтобы дать пространство и помочь вырасти, тимлид усиливает контроль. Больше ревью. Больше согласований. Больше вопросов в стиле “а ты подумал про…”. Формально - забота о качестве. Реально - страх стать ненужным.

Почему это блокер

Проблема не в защите. Защищать границы - нормально.

Проблема в том, КАК ты защищаешь. Из уверенности в своих силах - или из страха, что отберут? Первое - лидерство. Второе - агрессия, которую люди чувствуют. И уходят.

Если провести аналогию с системами: это как микросервис, который вместо того чтобы предоставлять API для взаимодействия, закрывает все порты и отвечает 403 на любой запрос. Технически он работает. Но система вокруг него деградирует.

Навык

Различать реальную угрозу и фантомную. Один вопрос себе: “я сейчас защищаю качество - или защищаю свое эго?”

Блокер 2: Жажда признания

На самом деле это про обратную связь.

Как это выглядит

Ты сделал отличную работу. Спроектировал систему, которая выдерживает нагрузку. Провел review процесс, который поднял качество кода в команде. Решил проблему, которую до тебя не могли решить полгода.

И тишина. Никто не подошел и не сказал “классная работа”. Руководитель молчит. Команда приняла результат как должное.

В этой тишине мозг начинает додумывать: “наверное, я плохо работаю”. Или хуже: “наверное, они не ценят то, что я делаю”.

Знакомая история: архитектор выстроил процесс API-review для системных аналитиков. Качество спецификаций выросло. Количество багов на этапе интеграции упало. Но руководитель ни разу не сказал “хорошая работа”. И в какой-то момент архитектор начал задаваться вопросом - а стоило ли вообще тратить на это время.

Еще пример. Senior-разработчик потратил месяц на рефакторинг критического модуля. Код стал чище, тесты - надежнее, время деплоя сократилось вдвое. На ретро об этом даже не упомянули. Senior начал демотивироваться - не потому что работа была бессмысленной, а потому что никто не заметил.

Почему это блокер

Во взрослой жизни никто не придет и не скажет “ты молодец”. Это делали родители. А на работе - тишина. И в этой тишине мозг начинает додумывать.

Если смотреть на это как на систему: у тебя нет observability для собственной ценности. Нет метрик, нет дашборда, нет алертов. Ты работаешь вслепую и полагаешься на единственный индикатор - внешнюю похвалу. А этот индикатор ненадежен. Он зависит от настроения руководителя, от культуры компании, от тысячи факторов, которые ты не контролируешь.

Навык

Либо научиться просить обратную связь - это не слабость, это зрелость. Либо выстроить внутреннюю опору, которая не зависит от чужих слов.

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

Блокер 3: Опыт как ловушка

Большой опыт создает иллюзию: “я больше знаю - мне должны”.

Как это выглядит

Совещание. Ты - самый опытный в комнате. Junior предлагает решение. Ты видишь в нем проблемы. И вместо того чтобы задать вопрос - “а что будет при нагрузке 10x?” - ты говоришь: “нет, так не делают, я десять лет занимаюсь этим и знаю”.

Формально ты прав. Решение действительно может не выдержать нагрузку. Но ты убил две вещи: инициативу junior-а и возможность для команды научиться думать самостоятельно.

Другой пример. Опытный тимлид приходит в новую команду. У него за плечами три успешных проекта с определенным стеком. Команда использует другой подход. Вместо того чтобы разобраться, почему выбран именно этот подход, тимлид начинает продавливать свой. Не потому что он лучше - а потому что знакомый. И потому что признать чужой подход = признать, что твой опыт не универсален.

Я сам ловлю себя на этом. Иногда давлю опытом вместо того чтобы слушать. И каждый раз, когда ловлю себя на этом, задаю вопрос: я сейчас учу - или доказываю?

Почему это блокер

Мир трансформируется. Старые шаблоны рушатся. В эпоху AI вчерашний эксперт сегодня учится заново. Опыт - ценность, но не валюта для обмена на покорность.

Если как систему: это legacy-сервис с hardcoded конфигурацией. Когда-то он работал отлично. Но мир вокруг изменился, а он все еще ожидает запросы в старом формате. И вместо того чтобы адаптировать API - требует, чтобы все остальные адаптировались под него.

Навык

Относиться к коллегам как к равным. Независимо от разницы в опыте. Это не значит игнорировать свой опыт - это значит делиться им через вопросы, а не через давление.

Три блокера. Три навыка. Ни один - про технологии

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

Как в любом проекте: чтобы увидеть архитектурные проблемы, нужен взгляд снаружи. Тот, кто внутри системы, видит отдельные симптомы. Тот, кто снаружи - видит паттерн.

Лидерство начинается не с архитектуры систем, а с архитектуры мышления. И если ты чувствуешь, что застрял - возможно, дело не в том, что ты мало знаешь. А в том, что пора посмотреть на свое мышление как на систему и провести ему честный аудит.

Архитектура памяти для AI-агентов: как я научил Claude Code помнить

Wed, 11 Feb 2026 00:00:00 +0000

Боль: агент с амнезией

Каждый, кто работает с AI-агентами, знает ощущение: ты объяснил контекст проекта, показал структуру, обсудил решения - а в следующей сессии агент всё забыл. Опять здрасьте. Опять “расскажите про ваш проект”.

Это как работать с архитектором, у которого каждое утро стирается память. Он талантлив, быстр, но каждый день - новый человек.

У меня 12+ активных контекстов: рабочие проекты (Wildberries), личные проекты (aitrader, archlint), блог, коучинговая практика, обучение, целеполагание. Переключение между ними без памяти превращалось в ритуал: 5-10 минут на “загрузку контекста” в начале каждой сессии.

Стало ясно: нужна архитектура памяти.

Как устроена человеческая память

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

flowchart TD A["Входящие данные"] --> B["Рабочая память\n(Short-Term)\nАктивные задачи,\nтекущий контекст"] B --> C{"Фильтр ценности\n(еженедельный ревью)"} C -->|"Ценно"| D["Долговременная память\n(Long-Term)\nПаттерны, принципы, уроки"] C -->|"Обработано"| E["Архив\n(забыто, но доступно)"]

У людей так же:

Рабочая память (Short-Term) - то, с чем работаешь прямо сейчас. Ограничена: ~7 элементов одновременно. Через 3-6 месяцев без обращения - забывается.
Долговременная память (Long-Term) - дистиллированные знания. Не “что я делал во вторник”, а “какой паттерн я увидел за три месяца работы”.
Архив - не удалено, но не на поверхности. Доступно при целенаправленном поиске.

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

Архитектура решения

Три уровня памяти

Я реализовал три уровня, зеркалирующих человеческую модель:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


~/my/org-roam/
+-- Short-Term-Memory/ # Рабочая память (3-6 месяцев)
| +-- Wildberries/ # Рабочий контекст
| +-- Coaching/ # Коучинговые сессии
| +-- daily/ # Ежедневные заметки
| +-- todos.md # Задачи
|
+-- Long-Term-Memory/ # Долговременная память
| +-- Coaching/ # Методики, паттерны, кейсы
| +-- Architecture/ # Архитектурные решения
| +-- Posts/ # Публикации
| +-- Personal/ # Личные принципы
|
+-- Archive/ # Архив (по месяцам)
 +-- 2026/
 +-- 01-January/
 +-- 02-February/

Short-Term - inbox для всего нового. Сырые заметки, текущие задачи, эксперименты. Максимум 50 активных файлов. Если больше - пора делать ревью.

Long-Term - база знаний. Сюда попадает только то, что прошло фильтр ценности:

Переиспользуемость (применимо 3+ раз)
Обучающая ценность (ага-момент, важная ошибка)
Референсная ценность (пример для копирования)

Archive - завершенные проекты, обработанные заметки. Не удалено, но убрано с глаз.

Контексты: переключение за секунду

Вторая проблема - переключение между проектами. Решение: система контекстов.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


{
 "contexts": {
 "coaching": {
 "name": "coaching",
 "description": "Коучинговые сессии и практика развития",
 "directory": "~/my/coaching",
 "memory": {
 "short_term": "~/my/org-roam/Short-Term-Memory/Coaching",
 "long_term": "~/my/org-roam/Long-Term-Memory/Coaching"
 }
 },
 "archlint": {
 "name": "archlint",
 "description": "ArchLint - линтер архитектуры Go проектов",
 "directory": "~/my/archlint",
 "memory": {
 "short_term": null,
 "long_term": null
 }
 }
 }
}

Каждый контекст знает:

directory - рабочая директория проекта
memory.short_term - где хранить текущие заметки
memory.long_term - где хранить дистиллированные знания

Переключение: одна команда /w coaching - и агент знает где он, что помнить, какие файлы читать.

Индекс активностей: навигация по всему

Контексты решают проблему “где я”. Но остается вопрос: “где искать информацию по теме X?”. Для этого - глобальный индекс активностей.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


### Коучинг / Практика

- Keywords: сессия, клиент, практика, рефлексия
- Файлы:
 - Практика: ~/my/org-roam/Long-Term-Memory/Coaching/03-Практика/
 - Гайды сессий: ~/my/org-roam/Long-Term-Memory/Coaching/session-guides/INDEX.md

### Здоровье и психология

- Keywords: психолог, здоровье, границы, стыд
- Файлы:
 - Темы: ~/my/org-roam/Long-Term-Memory/Темы для психолога.md
- Связанные активности: Коучинг / Запросы для проработки

Принцип работы:

flowchart TD A["Промпт пользователя"] --> B["Поиск по keywords\nв memory-index.md"] B --> C{"Найдена\nактивность?"} C -->|"Да"| D["Работай в её контексте"] C -->|"Нет"| E["Спроси пользователя,\nпредложи варианты"]

Кросс-контекстный поиск: связи между контекстами

Самая интересная архитектурная задача. Информация часто пересекает границы контекстов.

Пример: тема “границы” может всплыть в коучинге (запрос клиента), в психологии (тема для терапии), в рабочем контексте (обратная связь коллеге). Как не потерять связь?

Решение: кросс-ссылки на уровне глобального индекса, а не дублирование информации между контекстными индексами.

flowchart TD G["memory-index.md\n(глобальный индекс)"] --> C1["Coaching\nINDEX.md"] G --> C2["Здоровье\n(файлы)"] G --> C3["Работа\nINDEX.md"] G --> C4["..."] C1 -.-|"кросс-ссылка"| C2 C2 -.-|"кросс-ссылка"| C3 style G fill:#0f3460,color:#fff style C1 fill:#533483,color:#fff style C2 fill:#533483,color:#fff style C3 fill:#533483,color:#fff style C4 fill:#333,color:#999

Правило: каждый контекстный индекс отвечает только за свой контекст. Связь между контекстами - через поле “Связанные активности” в глобальном индексе.

1
2
3
4
5
6


## Кросс-ссылки между активностями

| Активность A | Активность B | Связь |
|--------------------------|------------------------|-------------------------------------|
| Коучинг / Запросы | Здоровье и психология | Запрос #11 = Тема #2 (границы) |
| Семья | Коучинг / Запросы | Запрос #3 (темы с супругой) |

Антипаттерн: дублировать ссылки на “Темы для психолога” внутри Coaching/INDEX.md. Это нарушает single responsibility - индекс коучинга не должен знать про психологию. Связь - только через глобальный уровень.

Жизненный цикл знаний

Данные без обработки - мусор. Система памяти работает, только если есть процесс трансформации.

flowchart LR subgraph ST ["Short-Term (сырые данные)"] A1["Заметки по сессии\nс клиентом X"] A2["Тикеты проекта\nархитектуры"] A3["Исследование\nTarjan алгоритма"] end subgraph LT ["Long-Term (знания)"] B1["Паттерн: Работа с\nпрокрастинацией\nчерез ценности"] B2["ADR-0042: Выбор\nмежду монолитом\nи микросервисами"] B3["Библиотека\nалгоритмов\nпоиска циклов"] end A1 -->|"трансформация"| B1 A2 -->|"трансформация"| B2 A3 -->|"трансформация"| B3

Критерии перехода в Long-Term

Не всё заслуживает долговременной памяти. Четыре фильтра:

Переиспользуемость - применимо 3+ раз (методики, шаблоны, чек-листы)
Обучающая ценность - ага-момент, важная ошибка, смена парадигмы
Референсная ценность - пример для копирования (код, кейс, формат)
Паттерн - повторяющаяся проблема + решение

Всё остальное - одноразовые заметки, устаревшие TODO, рутинные логи - удаляется или уходит в архив.

Еженедельный ревью

Раз в неделю - 30-40 минут на обработку Short-Term:

Просмотреть файлы за неделю
Выделить ценное для Long-Term
Трансформировать: сырые данные -> структурированные знания
Архивировать обработанное
Удалить мусор

Метрики здоровой системы:

Short-Term: 30-50 активных файлов
Long-Term: +2-5 новых записей в неделю
Archive: регулярное пополнение

Параллель с коучингом

Когда я проектировал эту систему, я заметил параллели с тем, что изучаю в коучинге.

Short-Term = Рабочая осознанность

Когда человек разбирается в сложной ситуации, он сначала выгружает всё, что на поверхности: факты, эмоции, людей, обстоятельства. Это рабочая память - хаотичная, перегруженная, но актуальная. Short-Term Memory в моей системе работает так же: собирает всё, что сейчас активно, без фильтрации.

Long-Term = Мудрость через рефлексию

Long-Term - это не “запомнить всё”. Это “понять, что важно”. Лучшие инсайты приходят не в момент обсуждения, а позже - когда человек рефлексирует и видит паттерн. Еженедельный ревью - это та самая рефлексия, только для базы знаний.

Кросс-контекст = Системное мышление

Проблема редко живет в одном контексте. Одна и та же тема может всплыть и на работе, и в личных проектах, и в обучении. Кросс-ссылки в системе памяти - это способ видеть одну тему с разных сторон, расширить перспективу.

Architect of Thinking

Изучая коучинг, я разработал авторский фреймворк на стыке архитектуры и работы с мышлением - Architect of Thinking. Формула:

Контекст -> Цель -> Карта -> Узел -> Решение -> Шаг

Это ровно то, как архитектор работает с системой: сначала изучи (контекст), определи цель, построй карту, найди bottleneck (узел), спроектируй решение, сделай первый шаг. Тот же подход - к человеческим задачам.

Результаты

До системы памяти:

5-10 минут на “загрузку контекста” каждую сессию
Потеря решений между сессиями
Дублирование работы
Невозможность связать темы между контекстами

После:

Переключение контекста за 1 команду
Знания накапливаются и структурируются
Связи между контекстами через кросс-ссылки
Еженедельный ревью превращает данные в знания

Что дальше

Система живая - она развивается вместе с моими проектами. Следующие шаги:

Автоматизация ревью (AI-помощник для еженедельной обработки Short-Term)
Семантический поиск по Long-Term Memory
Версионирование знаний (как знания меняются со временем)

Но главный урок не технический. Проектируя память для AI-агента, я лучше понял, как работает моя собственная. И это, пожалуй, самый ценный побочный эффект.

Исходный код и конфигурации описаны для Claude Code (Anthropic CLI). Подход применим к любому AI-агенту с файловой системой.