От книжных заметок к агентной разработке: AMA с подписчиками

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

Дальше чтение встраивается в публикационный процесс 6D: найти материал, прочитать, обсудить, описать, отредактировать и доставить аудитории. Сложная база знаний не является целью сама по себе. В эфире ей противопоставлены простые Markdown-файлы и навыки, которые можно переносить между инструментами. Книга и проект System Design Space показывают следующий шаг: разрозненные заметки становятся картой решений и материалом, которым можно пользоваться повторно.

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

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

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

Экономика AI различается по размеру компании: маленькая команда быстрее меняет весь процесс, крупная получает больший абсолютный эффект, но платит за интеграцию, безопасность и координацию. Финальный вопрос об AGI и ASI остаётся сценарием, а не прогнозом. Если системы научатся выполнять всё более длинные цепочки задач, узким местом станут постановка цели, согласование целей, независимая проверка и право принимать последствия. Поэтому даже продакт без инженерного опыта может собирать решения, но продукт для боевого контура всё равно требует инженерной рамки и явного владельца риска.