AI on Михаил Шогин

Спека как живой контракт: SPDD, archlint и двусторонний sync

Wed, 29 Apr 2026 00:00:00 +0000

Симптом

LLM в кодовой базе ускоряет одного разработчика. Команда от этого не ускоряется — наоборот, на ревью обрушивается поток сгенерированного кода, который никто не успевает понять. Спека, написанная на старте задачи, через неделю уже не описывает то, что в master. Кто-то правит код, кто-то правит .md, через месяц расхождение замолчано.

Это не про дисциплину команды. Это про архитектуру процесса, в которой “спека” и “код” не имеют формальной связи.

Диагноз от Thoughtworks

28 апреля 2026 на сайте Мартина Фаулера вышла статья Structured Prompt-Driven Development от Wei Zhang и Jessie Xia. Они формулируют проблему точнее, чем я: “Local speed improves. But that doesn’t automatically translate into system-level throughput.”

Их предложение в трёх пунктах:

Промпт — это first-class артефакт. Версионируется, ревьюется, переиспользуется как код. Не реплика в чате.
REASONS Canvas — 7-частная структура промпта: Requirements, Entities, Approach, Structure, Operations, Norms, Safeguards. Первые четыре — абстракция, пятый — исполнение, последние два — governance.
Замкнутая петля между промптом и кодом с правилом, что обновлять первым:
- изменение поведения -> сначала промпт, потом код
- рефакторинг -> сначала код, потом sync обратно в промпт

Третий пункт — главное. Он превращает вечный спор “что source of truth” в процедуру.

Где это совпало с моей практикой

У меня уже был свой spec-driven workflow:

~/my/archlint/templates/specifications/spec-template.md — шаблон спеки с разделами Architecture, Requirements, Acceptance Criteria, Implementation Steps. Размерные градации XS/S/M/L/XL.
Правило в ~/.claude/rules/spec-workflow.md: “задача >30 минут или >3 шагов — обязательно спека до старта”.
Команда /ms-add-spec в Claude Code, которая генерирует спеку под задачу.
archlint — статический анализатор, который валидирует архитектурные правила (200+) на графе из AST.

REASONS Canvas почти один в один ложится на мой шаблон:

REASONS	Мой шаблон
R Requirements	## Requirements (FR1, FR2, …)
E Entities	## Architecture / Data Model (UML Class)
A Approach	## Overview / Solution Summary
S Structure	## Architecture / Component Overview (C4)
O Operations	## Implementation Steps
N Norms	(не было отдельного раздела)
S Safeguards	(не было отдельного раздела)

Совпадение на 70-80%. Архитектурный governance у меня вообще сильнее — archlint проверяет автоматически то, что в SPDD держится на ревьюере-человеке.

Где SPDD добавил то, чего не было

Два пункта, которые у меня отсутствовали или были сформулированы неверно.

1. Спека “неизменна в процессе”

В моём spec-workflow.md буквально стояла формулировка:

Спека = ЧТО делать (неизменна в процессе)

Это противоположно идее живого артефакта. Спека написана, согласована, перенесена в inprogress/ — и потом никем не трогается, пока задача не закроется. На практике это значит, что любая правка реализации, отличающаяся от плана, проваливается между спекой и кодом.

2. Norms и Safeguards неявные

Стандарты команды (как именно мы оборачиваем ошибки, какой logger, какие naming-конвенции) у меня живут в куче .md файлов: ~/.claude/rules/architecture.md, проектные CLAUDE.md, в чате. На уровне отдельной спеки их явно никто не выносит. Авторы SPDD выделяют:

Norms — стандарты как принято писать. Часть автоматизирована (golangci-lint, archlint), часть нет.
Safeguards — неприкосновенные инварианты. Нарушение — стоп, не warning. Обратная совместимость, perf budgets, security boundaries.

Когда они в одной странице со спекой, тихий рефактор поперёк стандарта становится заметным на ревью.

Что я в итоге сделал

Два патча, оба сегодня.

Патч 1: `~/.claude/rules/spec-workflow.md`

Удалил “Спека неизменна”. Заменил на “Спека — живой контракт, синхронизирован с кодом всегда”. Добавил раздел “Двусторонняя синхронизация” с явным правилом prompt-first vs code-first:

1
2
3
4
5


Изменение поведения (publicly-exposed контракт, бизнес-логика, валидация)
-> сначала спека, потом код

Рефакторинг (поведение не меняется)
-> сначала код, потом sync обратно в спеку

И отдельный раздел “Norms и Safeguards: governance внутри спеки” с примерами и привязкой к archlint/golangci-lint.

Патч 2: `~/my/archlint/templates/specifications/spec-template.md`

Добавил две секции после Acceptance Criteria:

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


## Norms

- N1: error wrapping через fmt.Errorf("%w") или errtrace.Wrap
- N2: логирование через slog с контекстом
- N3: naming - DB snake_case, JSON camelCase

Автоматизировано:
- [ ] golangci-lint passes (errcheck, errorlint, sloglint)
- [ ] archlint passes (layered, fan-out, ISP)

## Safeguards

- S1: обратная совместимость публичного API в рамках minor релиза
- S2: p99 latency endpoint X не растёт более чем на 10%
- S3: нет утечки PII в логи и метрики

Проверка:
- [ ] Smoke test на обратную совместимость
- [ ] Бенчмарк до/после
- [ ] Аудит логов на чувствительные поля

Размерные градации те же: для XS Safeguards обычно не нужны, для M/L/XL — обязательны.

Что я НЕ взял

Не взял CLI openspdd и команду /spdd-prompt-update. Слишком много церемонии для одиночной работы и для команды без отдельного workflow-инженера. У меня та же дисциплина держится на:

/ms-add-spec — создать спеку
/ms-checkpoint — зафиксировать прогресс на длинной задаче
archlint — валидация Norms+Safeguards автоматически где можно
Code review через GitLab — двусторонний sync проверяется на ревью

Не взял правило “никогда не редактировать промпт руками”. У них это compensation за CLI-managed lifecycle. У меня его нет, и руками править .md спеку — нормальная операция.

Не взял заявление про “~99% intent alignment”. Это маркетинг, кейс N=1.

Двойная оптика

Технический слой статьи: дисциплина для AI-кодинга в команде.

Архитектура мышления за этим: проблема, которую решают авторы — не “AI пишет неправильный код”, а “bandwidth ревьюера не растёт со скоростью генератора”. Когда LLM выдаёт результат быстрее, чем человек успевает его понять, узкое место — когнитивная пропускная способность того, кто принимает изменения. SPDD сжимает то, на чём держится ревью, до одного артефакта (Canvas), чтобы он влезал в bandwidth.

Это та же задача, про которую я говорил на Стачке — контроль сложности через граф. Только на уровне процесса, а не статического анализа.

archlint = governance внутри кода (граф, правила, инварианты). SPDD/спека = governance над изменениями (контракт между намерением и реализацией).

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

Когда есть оба — каждый коммит проходит и через “не сломал ли архитектуру” (archlint), и через “соответствует ли намерению” (спека). На ревьюера падает только то, что обе автоматизации пропустили.

Ссылки

Оригинал статьи: Structured Prompt-Driven Development
openspdd (Thoughtworks-affiliated CLI): https://github.com/gszhangwei/open-spdd
archlint: https://github.com/mshogin/archlint

Совет умирает. Вопрос остаётся

Sat, 25 Apr 2026 00:00:00 +0000

Я 20 лет копил техническую экспертизу. За последние полтора года значительная её часть стала доступна любому, у кого есть подписка на нейросеть за 20 долларов.

Этот вопрос всплывает у меня периодически: насколько ценен мой опыт сегодня?

AI не “плохо отвечает”. AI поддерживает

Да, AI знает глубже, шире, точнее меня. И всё же есть особенность: AI поддерживает. Какое бы направление оператор ни выбрал - AI развивает именно выбранное.

Это даже не плохо. Молодой инженер с GPT движется в проблеме быстрее, чем я когда-то лопатил Stack Overflow и форумы по выходным.

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

Но смотрите дальше. Говорю AI: “Стоп. В моём прошлом проекте этот путь не сработал. Давай развернёмся”. Он отвечает: “Точно, отличная идея”. И теперь поддерживает развёрнутый вариант.

AI равно поддерживает любую мою сторону. И прежнюю, и развёрнутую.

И вот это - мой настоящий вопрос. На что опираться, если AI быстрее меня в ответах и подыгрывает любому моему выбору?

Поворот, которого я не ожидал

Ответ пришёл с неожиданной стороны: в этом году я учусь на коуча. Скоро экзамен ICF Level 1.

И эта учёба меня прижала.

Я всю жизнь работал в том же режиме, что AI. Только медленнее.

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

Человек кивает. Уходит.

Через неделю приходит снова. С тем же вопросом. В новой обёртке.

И я не понимал почему так.

Сейчас понимаю. Я отвечал на его слова. А не на его настоящий вопрос - который под словами: страх, сомнение, что-то очень его, во что мой совет даже не пытался попасть.

Что меняется

Учусь делать другое.

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

Это медленнее. Менее эффектно. И сложнее, чем выдать ответ за тридцать секунд.

Но самое интересное и самое сложное - дальше.

Когда у человека загорается лампочка - “Ага! Я понял!” - это не финиш. Это эмоциональный всплеск. Через два дня он рассасывается, и человек остаётся с тем же вопросом, что в начале.

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

Где мой компас

И вот тут связалось.

AI даёт ответы за секунды. Я давал ответы за минуты. Это - то, что заменяется.

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

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

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

Когда вам в последний раз помог не совет, а правильно поставленный вопрос?

Фаулер про LLM и разработчиков: cognitive debt, supervisory programming и кто на самом деле под ударом

Fri, 13 Feb 2026 00:00:00 +0000

Мартин Фаулер опубликовал заметки с встречи senior-разработчиков, посвященной LLM. Не очередной хайп про “AI заменит всех” - а трезвый разбор от людей, которые пишут код десятилетиями.

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

Mid-level под ударом, а не джуны

Обычно все переживают за junior-разработчиков: их-то заменят первыми. Фаулер с группой пришли к обратному выводу.

Джуны адаптивны. Они росли с LLM, умеют ими пользоваться, открыты к новому. Сеньоры понимают архитектуру, видят систему целиком, эффективно управляют агентами - примерно как управляют джунами.

А mid-level? Они сформировались без LLM, но еще не набрали достаточно опыта, чтобы эффективно ими управлять. Застряли между двумя мирами.

На практике я вижу это так: mid-level разработчик умеет писать код. Хорошо умеет. Но когда LLM генерирует код быстрее - “умение писать код” перестает быть конкурентным преимуществом. А понимание “зачем этот код нужен”, “как он вписывается в систему”, “какие trade-offs мы принимаем” - это уже территория сеньоров.

Один из участников рассказал показательную историю: сеньоры в их компании были резко против LLM. Но когда их заставили поработать руками - треть моментально стала pro-LLM. Практический опыт важнее теоретических страхов. Как пошутили на встрече, некоторые негативные мнения о LLM “остались в январе”.

Что делать mid-level

Если ты mid-level - у тебя есть окно. Не в том, чтобы учиться промптить. А в том, чтобы быстрее набирать архитектурное мышление: понимание систем, trade-offs, бизнес-контекста. То, что LLM пока делает плохо.

Cognitive debt опаснее technical debt

Это, на мой взгляд, самый ценный тезис. Фаулер ссылается на исследование Margaret-Anne Storey и проводит параллель с technical debt.

Её кейс: студенческие команды строили продукт, генерируя код с помощью LLM. К 7-8 неделе одна команда уперлась в стену - любое изменение ломало что-то неожиданное. Сначала обвинили технический долг. Но реальная проблема была в другом: никто в команде не мог объяснить, почему были приняты те или иные решения. Shared understanding - общее понимание системы - фрагментировалось и исчезло.

Фаулер разделяет это на два слоя:

Cruft (хлам в коде) -> в когнитивной сфере это ignorance (невежество) - незнание кода и домена
Debt (долг как метафора стоимости) -> либо платишь “проценты” (каждое изменение дороже), либо “гасишь тело” (инвестируешь в понимание)

Это точное попадание в то, что я вижу при приемке проектов. Не раз сталкивался с ситуацией: код написан грамотно, тесты есть, линтеры проходят - но никто не может объяснить, почему выбрана такая декомпозиция сервисов. Или зачем нужен этот промежуточный слой. Документация говорит “что”, но не говорит “зачем”.

С LLM-агентами cognitive debt будет масштабироваться: код генерируется быстрее, чем команда успевает его осмыслить. Скорость создания кода перестает быть ограничителем. Ограничителем становится скорость понимания.

Как с этим работать

Несколько практик, которые помогают:

ADR (Architecture Decision Records) - фиксируем не “что решили”, а “почему решили и какие варианты отвергли”
Коучинговые вопросы на ревью - вместо “используй Strategy pattern” спрашивать “какие варианты ты рассмотрел? какие trade-offs?”
Обязательный контекст в PR - не просто diff, а “зачем” это изменение нужно

Если LLM генерирует код - пусть генерирует и ADR к нему. Хотя бы черновик для ревью.

DevEx и Agent Experience - это круг

Laura Tacho сказала фразу, которая заслуживает стать мемом:

The Venn Diagram of Developer Experience and Agent Experience is a circle

Всё, за что годами боролись в developer experience - гладкий тулинг, понятная документация, чистая модульность, осмысленные имена - оказывается, помогает и LLM-агентам. Хорошая модульность и descriptive naming так же полезны для трансформера, как и для “более мягких нейронных сетей” (мозгов).

И горькая ирония: менеджмент готов инвестировать в “smooth path для LLM”, но не готов был делать это для людей. Экзекьютивам не жалко денег на роботов, но жалко на разработчиков.

Из моего опыта: чистая архитектура с явными зависимостями, маленькими интерфейсами и четкими слоями - это ровно то, что позволяет LLM-агенту эффективно работать с кодобазой. Когда я настраивал Claude Code для работы со своими проектами, разница была заметна сразу: в проекте с чистой архитектурой агент находит нужный контекст за секунды. В проекте-монолите с неявными зависимостями - путается, галлюцинирует, предлагает изменения не в тех файлах.

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

Supervisory programming и менеджерское выгорание

Камилла Фурнье заметила:

The part of “everyone becomes a manager” in AI that I didn’t really think about until now was the mental fatigue of context switching

Тренд “один программист управляет несколькими агентами” несет с собой ровно ту же болезнь, от которой годами страдают менеджеры: усталость от переключения контекста. Держать в голове 5 параллельных задач, ревьюить результаты из разных контекстов, ловить ошибки в коде, который ты не писал - это менеджмент, а не программирование.

Фаулер осторожно предполагает, что два человека + агенты могут быть эффективнее, чем один человек + много агентов. Парное программирование нового формата: два мозга ловят ошибки “джинна” лучше, чем один.

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

Workload creep

Фаулер также цитирует исследование из Harvard Business Review: в компании на 200 человек после внедрения AI сотрудники стали работать быстрее, брать больше задач, работать больше часов - часто без просьбы. Звучит как мечта менеджера. Но за первоначальным всплеском приходит: cognitive fatigue, выгорание, ухудшение качества решений.

Это классический паттерн. Новый инструмент дает эйфорию -> берешь больше -> не замечаешь, как нагрузка выросла -> burnout.

Размер команд

Уменьшатся ли команды? Фаулер склоняется к “нет”. Two-pizza teams (5-8 человек) останутся примерно того же размера - но будут делать значительно больше. Есть что-то фундаментальное в размере команды, что балансирует выгоды сотрудничества с издержками координации. LLM не едят пиццу, но они и не добавляют в team dynamics.

Будущее IDE

Отдельная тема - будущее IDE. LLM не заменяют IDE, а встраиваются в них. Переименовать функцию через LLM - это как забивать гвоздь микроскопом. Но LLM может оркестрировать инструменты IDE: увидеть, что “person” нужно переименовать в “contact” во всех контекстах (функции, поля, документация, тесты), и использовать детерминистические рефакторинги IDE для каждого из них.

Мне как пользователю Emacs это особенно резонирует. IDE - это мощный инструмент, но мало кто использует его на полную. LLM может стать тем слоем, который знает возможности IDE лучше пользователя и подсказывает, когда использовать LLM, когда - детерминистический рефакторинг, а когда - их комбинацию.

Итого

Главные мысли из текста Фаулера:

Mid-level под ударом - не джуны, как все думали. Окно для роста: быстрее набирать архитектурное мышление
Cognitive debt > technical debt - с LLM код генерируется быстрее, чем осмысляется. Ограничитель теперь - понимание, а не написание
DevEx = Agent Experience - инвестиции в чистую архитектуру дают двойной ROI
Supervisory programming = менеджерское выгорание - context switching утомляет. Пара людей + агенты может быть лучше одиночки + много агентов
Workload creep - эйфория от AI -> перегрузка -> burnout. Классика

Текст Фаулера ценен тем, что он не про хайп и не про страх. Он про трезвую оценку: что меняется, что остается, и какие новые проблемы приходят вместе с новыми возможностями.

А ты замечаешь cognitive debt в своих проектах?

Архитектура памяти для 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-агенту с файловой системой.

AI не заменяет - AI меняет роль

Mon, 19 Jan 2026 00:00:00 +0000

Недавно наткнулся на статистику: 55% компаний, которые уволили людей из-за AI, теперь жалеют об этом. А исследование METR показало вообще странное - разработчики думают что с AI работают на 20% быстрее, а на деле оказалось на 19% медленнее.

И тут же читаю Хинтона, который говорит что через пару лет AI будет делать за минуты то, на что инженеру нужен месяц. А CEO AWS в ответ называет отказ от найма джуниоров “одной из самых глупых вещей, что слышал”.

Кто прав-то?

Мой опыт говорит - оба мимо. AI не заменяет людей. И не замедляет работу. Он просто меняет то, чем мы занимаемся.

Что я отдал AI

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

Звучит как будто я всё отдал. Но нет.

Что не отдам

Здоровье. Вот тут для меня чётко. Я не против если доктор использует AI - наоборот, хорошо бы. Но это должен быть доктор. С образованием. С опытом. AI как инструмент - да. AI вместо врача - нет.

То же самое с психологом. Мне нравится работать с живым человеком, и я не вижу как это можно заменить. С коучем - аналогично.

Всё что связано с моим здоровьем, с сознанием, с осознанностью - это только к профессионалам. Которые могут использовать AI в работе, но именно профессионалам.

Про этот “парадокс продуктивности”

Вот это исследование METR меня зацепило. Люди думают что быстрее, а на деле медленнее. Парадокс, говорят.

Не согласен.

Раньше как было? Ты мог попробовать один-два варианта реализации. Выбрал что-то, пошёл делать. Натыкаешься на проблемы - делаешь третью версию. Потом четвёртую. И всё это копится. Первая версия где-то лежит, вторая, третья - и ты уже на пятой, а legacy тянется.

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

Это не замедление. Это другой способ работы.

Джуниоры

CEO AWS сказал хорошо: “Как это будет работать через 10 лет, когда никто ничему не научился?”

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

Да, с AI можно делать сайты и телеграм-боты без особого образования. Но индустрия - это не только сайты и боты. Есть куча вещей, где нужна высшая математика. Где нужен computer science. Джуниоры нужны. И их надо учить.

Как изменилась моя роль

Писать код руками - уже нет смысла. Я теперь думаю про архитектуру. Проектирую системы. Делаю ревью. Валидирую то, что получилось.

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

Короче, роль сдвинулась. Раньше - исполнитель. Теперь - проектировщик и валидатор.

Что стало важнее

Системный подход. Вот эти истории про “героя-разработчика” который ночью всё починил, или “пожаротушителя” который везде успевает - это уходит. Ценятся люди, которые системно решают задачи.

И ещё один навык появился: строить свою систему работы с AI. Просто надиктовать промпт - не работает. Нужна именно система. Свои промпты, правила, скиллы, агенты.

Я трачу время не только на рабочие задачи, но и на эту систему. Это мой актив. Моя интеллектуальная собственность, если хотите.

К чему это всё

AI не заменяет специалистов. Он меняет то, чем они занимаются.

55% компаний жалеют об увольнениях не потому что AI не работает. А потому что они не поняли - роль людей изменилась, а не исчезла.

Меньше исполнения, больше проектирования. Меньше героизма, больше системы. Меньше кода руками, больше работы над своими инструментами.

Вот так оно сейчас выглядит. По крайней мере у меня.

Больше про AI в разработке и архитектуру: Telegram