AMA с подписчиками: чтение, карьера, пет-проекты и AI-разработка

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

Книга выбирается не из очереди «важного на всю жизнь», а по вопросу, который сейчас мешает думать или работать. Поэтому чтение становится частью более длинного цикла: встретить идею, проверить её о собственный опыт, обсудить, объяснить другим и вернуться позже с новым контекстом. Повторное чтение «Пиши, сокращай» или Талеба полезно именно потому, что читатель уже другой.

Публичный ответ удобно описывать как 6D: Discovery — найти сигнал; Digest — разобрать источник; Discuss — столкнуть идею с людьми и контраргументами; Describe — сформулировать собственную модель; eDit — сократить и проверить; Deliver — выпустить материал. Заглавные буквы образуют 6D не ради мнемоники: ценность возникает только тогда, когда сырая находка дошла до проверяемого результата.

Технический ответ оказался менее романтичным. Экспериментальная база с контуром загрузки, полнотекстовым, векторным и графовым поиском существует, но в повседневной работе чаще выигрывает Git-репозиторий с Markdown-файлами и явными навыками агентов. Он проще проверяется, версионируется и переносится между инструментами. Сложность оправдана только после появления задачи, которую простая система действительно не решает.

Discovery → Digest → Discuss → Describe → eDit → Deliver

Пространство практики системного проектирования началось с рукописи и документа Google. Линейный текст хорошо объясняет последовательную модель, но архитектурное мышление формируется в выборе: увидеть ограничения, предложить варианты, получить подсказку только в нужный момент, посмотреть последствия и попробовать ещё раз. Поэтому сайт постепенно движется к задачам, объяснениям, интерактивным визуализациям, лабораториям и коротким проверкам понимания.

Будущая книга в издательстве «Питер» остаётся линейным маршрутом по теме, а пространство — нелинейной средой практики. На дату эфира ближайшие инкременты проекта скорее будут бесплатными; монетизация не определена. Важнее не объявить бизнес-модель раньше продукта, а проверить, действительно ли упражнения помогают переносить знание в решения.

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

С агентами такой стенд особенно полезен. Они позволяют быстро пройти от идеи до большой реализации, но одновременно требуют архитектурных рамок, CI/CD, самовосстановления и детерминированных проверок. Если проект нельзя проверить без ручного перечитывания каждого файла, ускорение генерации лишь переносит работу в конец цикла.

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

Для джуна это означает новый цикл обучения: сначала сформулировать гипотезу, затем направить агента, прочитать изменение, проверить поведение и объяснить решение. Для лида рост не сводится к следующему названию должности. Нужны подходящее место, время и готовность; культура Westrum помогает понять, проходит ли информация через систему или наказывается вместе с плохими новостями.

Это личный снимок на 23 августа 2026 года, не универсальный совет. Последний рабочий день — 31 августа; за плечами почти десять лет в одной большой технологической системе. Причина сформулирована как расхождение траекторий: компания и человек продолжают двигаться, но уже не обязательно в одну сторону. В сорок лет, с семьёй и финансовой подушкой, можно позволить себе другую форму риска, чем в начале карьеры.

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

Рабочий ответ — уменьшать не только размер набора изменений, но и пространство неоднозначности. Разработка от спецификации превращает намерение в критерии, план, задачи, реализацию и проверку. ADR фиксируют решения и компромиссы; один агент может реализовывать, другой — искать пропуски. Но смена модели не создаёт независимости, если обе читают один и тот же неполный контекст.

Поэтому нужны маленькие изменения и защитные ограничения: типы, линтер, статический анализ, тесты, проверки доступности, языков, ссылок, бюджета ассетов и поведения маршрутов. Агент разбора первопричин (RCA) полезен, пока знания об инциденте выражены в логах, метриках, трейсах и истории решений. Если причина живёт в голове эксперта или в неявной организационной границе, агент уверенно оптимизирует неполную модель. Ответственность остаётся у владельца изменения.

намерение → критерии приёмки → план → задачи → реализация → проверка

«Код почти бесплатный» не означает «изменение почти бесплатное». У маленькой компании агент может убрать заметную долю ручного исполнения и дать одному человеку возможность собрать продукт. В средней компании выигрыш быстро упирается в общий контекст и согласование между функциями. В крупной компании доминируют наследие, политики, идентичности, риски и стоимость доказательства, что локальное ускорение не повредило системе.

Отсюда неоднозначный эффект для SaaS и внутренних платформ. Тонкая оболочка вокруг доступной возможности модели становится уязвимой; глубокая интеграция, данные, доверие и изменение процесса сохраняют ценность. Но платформа, которую дорого поддерживать и невозможно заменить, превращается из актива в обязательство. Бесплатная генерация усиливает этот тест, но не отменяет организационные затраты.

Исследования Microsoft, DORA, NBER и материалы 3 AImigo ниже добавлены из подготовки. Они помогают проверить разговорную гипотезу, но не звучали как доказательства в самом эфире.

В эфире ответ был короче и жёстче подготовленного: рекомендация книги Элиезера Юдковского и Нейта Соареса о риске сверхчеловеческого интеллекта и разговор о проблеме согласования целей. Это сильная позиция о риске сверхчеловеческого интеллекта, а не нейтральный прогноз. MIRI продолжает работу и описывает стратегический поворот 2024 года; Safe Superintelligence заявляет безопасный сверхинтеллект своей единственной целью. Ни один из этих фактов сам по себе не доказывает, что задача решена или что известен срок.

Подготовленная рамка шире: AGI можно обсуждать по широте и уровню способностей, отдельно от автономии; ASI — как гипотетический переход к системам, превосходящим людей в большинстве когнитивных задач. International AI Safety Report, Levels of AGI, METR и другие источники полезны именно потому, что сохраняют неопределённость. График горизонта задач — не календарь «полной автоматизации».

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

Зрители расширили подготовленный маршрут. Кого читать, чтобы понимать будущее AI? Не одного трендсеттера, а несколько независимых каналов: инженерные разборы, продуктовые разговоры и первичные публикации. Как относиться к LLM как к «подсудимому»? Требовать доказательства: ссылки на контекст, воспроизводимый тест и явное различие между фактом, выводом и предположением.

Нужны ли Java, Go и Spring Boot? Да, когда это язык системы, которую предстоит понимать и менять; нет, если список технологий заменяет обучение инженерному суждению. Может ли сильный продакт без глубокой инженерной базы делать продукт с Lovable или Replit? Может собрать и проверить гипотезу, но рост радиуса последствий потребует архитектуры, безопасности, эксплуатации и людей, которые способны доказать корректность.

Общий ответ всего AMA — собирать не список правильных инструментов, а цикл обучения. Сформулировать вопрос, найти материал, построить модель, сделать ограниченный проект, проверить последствия и объяснить результат. Такой цикл переживает смену книг, языков, моделей и даже представлений о роли разработчика.