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

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

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

Но постепенно задач становилось больше. Вторая память уже должна была не просто сохранить запись, а понять её смысл, связать с прошлым, отличить план от сделанного и потом найти всё это по нормальному человеческому запросу. Добавились голос, изображения, документы, дневники и несколько процессов, которые хотелось запускать одновременно.

В какой-то момент одной системе стало плоховато.

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

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

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

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

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

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

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

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

И тут у меня возникла немного странная ассоциация с блокчейном.

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

Грубо говоря, хочется сделать блокчейн, только не блокчейн.

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

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

Одно устройство может искать по документам, которые уже лежат на нём. Другое возьмёт тяжёлую обработку. Третье останется интерфейсом, через который человек задаёт вопросы и получает ответы. Если локальной мощности не хватает, подключается облако.

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

Допустим, я спрашиваю, почему за последний месяц изменилось моё восстановление. Записи о питании могут находиться в одном месте, тренировки — в другом, показатели сна — в третьем.

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

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

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

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

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

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

В этом смысле централизация и децентрализация для меня не противники. Это два подхода, которые можно использовать одновременно. Вторая память остаётся одной для человека, хотя физически её данные и вычисления находятся в разных местах.

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

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

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

Есть задачи, которые всё равно потребуют одной большой GPU. Возможно, облако справится с ними дешевле и быстрее. А центр, управляющий распределённой системой, вполне может сам стать новым узким местом.

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

Если вы работали с распределёнными системами, локальными вычислениями или обработкой данных непосредственно на устройствах, напишите в комментариях: что здесь может не получиться?

Можно ли собрать одну вторую память из нескольких устройств, почти не перемещая между ними исходные данные? Где такая система сломается первой? И в какой момент окажется, что купить один мощный компьютер всё-таки было разумнее?

Вариант «купи нормальное железо и не выдумывай» тоже принимается. Но желательно с аргументами и цифрами.

Промежуточные заметки о том, почему сохранить информацию оказалось проще, чем научиться вовремя её возвращать.

На длинных задачах я постоянно упираюсь в одну и ту же проблему.

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

Открываешь новую — и значительную часть приходится рассказывать заново.

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

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

На коротких задачах это почти незаметно. На длинных постепенно возникает странное ощущение: вместо движения вперёд я всё чаще восстанавливаю собственное прошлое.

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

В июле я решил не только рассуждать об этом, а попробовать собрать такую систему технически.

Тогда всё выглядело довольно просто.

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

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

Начать я решил с дневника

Не с базы знаний по работе, не с архива всех принятых решений и не с попытки сразу сохранить всю жизнь.

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

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

Я могу написать:

Утренний протеин и добавки.

Могу прислать фотографию и добавить:

Одна таблетка.

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

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

Какой именно протеин? Какие добавки? Одна таблетка чего? Это действительно было принято или только лежало рядом на столе?

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

Исходную запись нужно сохранить именно такой, какой она была, а своё понимание держать отдельно. Если данных не хватает — оставить вопрос открытым и вернуться к нему позже.

Иначе вместо второй памяти довольно быстро получится очень уверенная художественная литература о собственной жизни.

Потом начался ремонт

Сначала мне казалось, что основная задача — надёжно сохранить запись и потом её получить.

Но проект повёл себя как ремонт квартиры.

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

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

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

В какой-то момент вокруг довольно простого дневника выросла целая конструкция.

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

Вот здесь я, кажется, и свернул не туда.

Я слишком рано начал строить большую систему вокруг ещё не законченного пользовательского сценария.

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

Всё описано, но живой путь пока не подтверждён.

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

То есть система не была просто набором документов. Но и настолько законченной, как можно было подумать по отчётам, она тоже не была.

Отдельные куски работали. Другие существовали в коде, но ещё не проходили всю реальную цепочку. Где-то описание уже успело обогнать фактическое состояние.

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

Самым дорогим оказалось не хранение данных

А потом я увидел, куда на самом деле уходят деньги и время.

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

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

В какой-то момент я понял, что значительная часть ресурсов уходит не на развитие системы, а на объяснение самой системе, что с ней происходило вчера.

На этом и сгорали токены. Много.

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

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

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

Тут я понял, что всё это время думал немного не о том.

Я пытался решить, как сохранить информацию.

Хотя сохранить её — как раз самая простая часть.

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

Настоящая вторая память должна не только помнить прошлое. Она должна понимать, какая его часть важна именно сейчас.

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

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

В общем, за первый месяц я понял: ценность памяти не в объёме сохранённого, а в качестве контекста, который она возвращает.

Почему одного хранилища оказалось мало

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

Но постепенно запрос стал шире.

Мне понадобилось не только место, которое помнит, но и личный ассистент, способный удерживать продолжение работы.

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

И тут началась другая путаница.

Для такой системы слова «обсуждалось», «запланировано», «сделано» и «проверено» должны означать совершенно разные вещи.

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

Человек обычно восстанавливает разницу по интонации и общей истории разговора. Значит, здесь её приходится хранить явно.

Иначе она будет очень хорошо помнить то, чего на самом деле никогда не происходило.

С самостоятельностью тоже всё оказалось не так романтично.

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

Выглядело забавно, пока речь шла только о сообщениях.

Но если система может менять данные или запускать действия, уже недостаточно просто сказать ей: «продолжай».

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

В итоге запрос на личного ассистента для меня сильно приземлился. Мне не нужен голос, который красиво отвечает на всё подряд. Нужен помощник, который помнит, где остановилась задача, достаёт нужный кусок прошлого и не говорит «готово» раньше времени.

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

Но теперь хотя бы понятно, где я свернул не туда. Я пытался сразу строить систему на вырост, хотя сначала стоило научиться честно помнить одну обычную фразу.

Ту самую: «утренний протеин и добавки».

Если она сохранится без фантазии, потом найдётся без отдельного расследования и вернётся именно тогда, когда понадобится, — значит, что-то начало получаться.

А пока это всё ещё стройка.

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

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

За последние пару лет у меня накопилось много параллельных разговоров с ИИ. В одних мы обсуждали рабочие проекты, в других — здоровье, обучение, личные задачи, какие-то мои идеи. Внутри каждого отдельного диалога всё обычно работает хорошо: модель помнит, с чего мы начали, знает предыдущие решения и понимает мои сокращения.

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

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

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

Формально почти всё сохранилось, но без понимания, где и что искать, вся эта информация почти не работала. Сообщения лежали в переписках, документы — в папках, презентация с названием «финальная_версия_7» тоже наверняка была на месте. Исчезло другое — состояние, в котором принималось решение: какую проблему я тогда решал, какие варианты уже попробовал, почему очевидный путь не подошёл, какое ограничение оказалось главным и где в итоге остановился.

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

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

Что изменил ИИ

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

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

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

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

Хотя здесь как раз и возникает проблема. Когда-то он это действительно знал и понимал, но реальный опыт не лежит в голове в виде аккуратной базы данных. Он постепенно стирается, смешивается и упрощается. Через несколько лет от сложного проекта может остаться внутреннее ощущение: здесь так лучше не делать. Возможно, оно однажды остановит от ошибки, но объяснить его другому человеку, а тем более передать системе, уже трудно.

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

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

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

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

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

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

Что я называю второй памятью

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

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

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

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

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

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

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

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

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

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

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

Начинающие, мидлы и сеньоры

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

Программа запускается, задание сдано, на экране всё выглядит правильно. Потом старший коллега задаёт довольно простой вопрос: «Почему ты сделал именно так?» — и выясняется, что между ответом модели и пониманием человека осталась пустота.

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

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

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

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

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

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

Во время сложного инцидента команда начинает искать человека, который «точно что-то об этом знает». Иногда он на другом совещании, иногда в отпуске, иногда уже работает в другой компании, но его номер всё ещё хранится у половины команды как последний элемент отказоустойчивости.

Человека находят. Он смотрит на ситуацию и говорит: «Нет, так делать нельзя. Мы уже проходили это раньше». Иногда одной этой фразы достаточно, чтобы остановить неправильное действие, но для передачи опыта её мало. Почему нельзя? Что именно произошло в прошлый раз? Какой признак он увидел сейчас? При каких условиях это решение всё-таки допустимо?

Если ответы остаются только у конкретного человека, организация не сохраняет опыт, а просто какое-то время пользуется его памятью. С появлением ИИ-агентов это становится ещё важнее. Чтобы поручить системе действие, мало научить её добиваться результата. Она должна понимать, где обязана остановиться, когда нужно позвать человека, какой риск недопустим и почему локально правильное действие может дать плохой результат для всей системы. В таких ситуациях накопленный опыт «как не надо и почему» может оказаться полезнее любой инструкции «как сделать».

От памяти к персональному ассистенту

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

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

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

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

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

Поэтому мне не нужен ассистент, который скажет: «Ты всегда делал так, поэтому я уже всё решил». Мне кажется более полезным другой разговор: «Раньше ты выбрал этот вариант, потому что действовали такие ограничения. Сейчас часть из них изменилась». Тогда прошлый опыт помогает принять новое решение, но не принимает его за человека.

Такая память должна принадлежать самому человеку. Модели и интерфейсы будут меняться: сегодня мы пишем текст, завтра разговариваем голосом, потом появится что-то ещё. Но история решений не должна исчезать вместе с очередным сервисом или навсегда оставаться запертой внутри него.

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

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

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

Пока же для меня достаточно одного вывода: собственный опыт пора перестать хранить только в голове.

Антон Кузьмин CTO Innostage· по материалам вебинара с Егором Богомоловым · 22 июля 2026

22 июля мы с Егором Богомоловым, основатель CyberED и Singleton Security, провели вебинар «Как выжить, когда рынок ИБ перестраивается». Название получилось тревожным, но разговор в итоге был скорее о возможностях. Мы обсуждали, как искусственный интеллект меняет экономику атак, зачем инженеру фундаментальные знания, почему опыт сеньоров становится основой для безопасной автоматизации и какие действия уже сегодня помогут студенту, мидлу и опытному специалисту сохранить профессиональную устойчивость.

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

Видеозапись эфира: «Как выжить, когда рынок ИБ перестраивается»

Начну с личной точки отсчета. В технологиях я около восемнадцати лет. Я пришел стажером в телеком, помню dial-up, DSL, первые крупные оптические сети и тот период, когда развитие ИТ казалось относительно понятным. В 2017 году я оказался в информационной безопасности и получил задачу построить SOC. Тогда выражение «безопасность в вакууме» звучало особенно точно: рынок во многом продавал риски, страхи, регуляторные требования и персональные данные, а компаниям еще приходилось объяснять, кто такой хакер и почему он вообще должен прийти именно к ним.

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

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

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

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

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

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

«Самый важный вопрос безопасника: что именно я защищаю?»

ИИ меняет не только профессию. Он меняет стоимость действия

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

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

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

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

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

«ИИ и агенты дают атакующему практически бесконечное количество возможностей проверять гипотезы на лету».

Атакующему достаточно одной лазейки. Защитнику нужно удержать весь объект

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

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

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

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

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

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

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

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

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

В этом смысле главный вопрос ближайшего периода связан не с тем, умеет ли агент выполнять действие. Вопрос в том, умеет ли организация безопасно дать ему право на это действие.

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

Другой пример ближе к реальной эксплуатации. Система видит подозрительную активность на сервере расчетов и предлагает немедленно его изолировать. Для модели это логичный шаг. Архитектор знает, что через этот сервер проходит закрытие операционного дня. Эксплуатация понимает, существует ли резерв. Владелец процесса знает цену остановки. ИБ оценивает риск сохранения соединения. Решение появляется только после сборки этих контекстов.

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

ПРАКТИЧЕСКИЙ СМЫСЛ ГРАНИЦ • цель агента должна учитывать функцию бизнеса и технический показатель, причем функция бизнеса задает приоритет; • критические действия должны иметь подтверждение, журналирование и понятный механизм отката; • запретные зоны, окна изменений и допустимые данные нужно задавать до подключения агента; • результат автоматизации должен проверяться так же строго, как изменение, выполненное человеком.

Опыт инженера превращается в границы для ИИ

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

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

Для бизнеса прежняя граница между ИТ и ИБ постепенно теряет смысл. Если организация перевела работу в цифровой контур, она ожидает, что цифровой бизнес будет функционировать. Сервис может остановиться из-за атаки, отказа оборудования, ошибки администратора, неудачного обновления, проблемы поставщика или неверного действия агента. Для руководителя итог один: нужная функция перестала выполняться.

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

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

«Инженер должен будет управлять определенным слоем результата».

Спираль инженерной работы: «я — мы — я — мы»

От универсального инженера — к специализации, затем к усиленному ИИ «я» и новому «мы» из людей и машин.

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

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

СПИРАЛЬ ИНЖЕНЕРНОЙ РАБОТЫ

ПЕРВОЕ «Я»

Универсальный инженер проходит путь от симптома до причины собственными руками.

ПЕРВОЕ «МЫ»

Рост цифрового контура приводит к специализации и распределению знаний между командами.

НОВОЕ «Я»

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

НОВОЕ «МЫ»

Люди и машины объединяются вокруг критической функции и общего результата.

Первое «я» я хорошо помню по началу карьеры. Доступ к информации был ограничен, технологий было меньше, а универсальный инженер часто проходил путь от симптома до причины самостоятельно. Левой рукой он помогал пользователю, правой настраивал маршрутизатор, затем проверял сервер, базу и приложение. Он мог не знать ответ заранее, но умел разбираться.

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

Затем пришла масштабная цифровизация. Количество систем, пользователей, интеграций и угроз выросло. Универсального знания стало недостаточно, и возникло первое «мы». Сеть, серверы, базы, разработка, эксплуатация, ИБ и SOC распределили между собой работу и ответственность.

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

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

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

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

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

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

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

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

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

Эта спираль объясняет, почему тезис о полной замене инженера слишком примитивен. Меняются масштаб личности и устройство команды. Человек сначала был универсалом, затем стал частью специализированного коллектива, сейчас снова получает индивидуальную силу, а дальше будет собирать новое «мы» из людей и машин.

«Все, что можно сделать по инструкции, рано или поздно будет отдано ИИ и автоматизировано».

Исчезнет не инженер. Исчезнет работа по инструкции

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

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

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

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

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

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

«Нас учили двум вещам: выкручиваться и разбираться».

Фундамент нужен не для памяти, а для проверки

Быстрый доступ к знаниям не обесценивает фундаментальное образование. Фундамент становится системой координат для проверки ответа модели. ИИ может объяснить технологию, написать код, разобрать лог и предложить конфигурацию. Человеку нужно понимать, зачем существует этот слой, как он связан с остальными и где предложение выглядит правдоподобно, но ведет к плохому результату.

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

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

Запоминать каждую команду конкретного производителя становится менее ценно. Команду модель подскажет за секунды. Ответ на вопрос «почему система устроена именно так и что сломается после изменения?» придется строить самому.

Отдельно я бы добавил к фундаменту умение мыслить системно. За последние годы одним из полезных для меня учебных опытов стала ТРИЗ, теория решения изобретательских задач. Она дала универсальный язык для декомпозиции сложной проблемы, поиска противоречий и выхода в надсистему. Методика старая, но в мире ИИ ее ценность только растет: модель быстро дает варианты, а человеку нужно правильно сформулировать проблему и увидеть, на каком уровне ее следует решать.

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

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

Способность быстро получить ответ перестает быть главным преимуществом. Главным становится способность оценить ответ и встроить его в реальную систему.

ЧЕТЫРЕ ОШИБКИ В РАЗГОВОРЕ ОБ ИИ • считать, что быстрый ответ равен пониманию системы; • ожидать, что одна подписка одинаково усилит атакующего и защитника; • предполагать, что фундаментальные знания больше не нужны; • сводить опыт сеньора к памяти о командах и настройках.

Освобождённое время становится профессиональным капиталом

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

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

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

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

ТРИ КАРЬЕРНЫЕ ОПТИКИ

СТУДЕНТ

Фундамент, стажировка, реальные задачи и привычка оставаться в проблеме.

МИДЛ

Вторая память, выход в надсистему и переход от продукта к классу задач.

СЕНЬОР

Инвентаризация опыта «как нельзя» и перевод его в границы для автоматизации.

Что делать студенту, мидлу и сеньору

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

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

Стажировка может стать самым ценным вложением в себя. Стажировки есть у интеграторов и у заказчиков. Есть целевые университетские группы, межвузовские SOC, пентест-сообщества, CTF, проектные лаборатории. Важно попасть в среду, где есть реальные задачи, неполные данные, опытные коллеги и возможность ошибаться без права исчезать после первой сложности.

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

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

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

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

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

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

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

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

Сеньору важно провести инвентаризацию этого опыта. Какие решения нельзя применять без теста? Какие изменения требуют участия владельца бизнеса? Где автоматический откат не спасет? Какие зависимости обычно остаются незадокументированными? Ответы на такие вопросы становятся будущей политикой работы агентов.

«Сеньоры обладают огромным знанием о том, как делать не надо. Именно на нем будет строиться новая инфраструктура».

Новая компетенция: AI Security Engineering

Кто-то должен определить запретные зоны, условия подтверждения, правила работы с данными, окна изменений, критерии отката и действия, которые формально решают задачу, но создают недопустимый риск. Это работа сильных мидлов и сеньоров. Без ИИ противодействовать скорости противника будет все труднее. Без опыта людей безопасно внедрить ИИ тоже не получится.

Отсюда появляется отдельная компетенция AI Security Engineering. Корпорации уже задают практический вопрос: как оставить сотрудникам возможность автоматизировать рутину и при этом контролировать, чтобы агент не удалил лишнее, не вывел данные и не изменил критический контур без разрешения.

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

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

ЧТО ЗНАЧИТ УПРАВЛЯТЬ ГРАНИЦАМИ ИИ • определять разрешенные модели, данные, системы и классы действий; • встраивать подтверждение человека для критических операций; • обеспечивать журналирование, наблюдаемость и откат; • проверять созданный код и конфигурации до применения; • контролировать теневое использование и обновлять правила по мере изменения моделей.

Практика: что можно начать делать уже сейчас

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

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

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

КАК ПОКАЗАТЬ ИНЖЕНЕРНУЮ ЦЕННОСТЬ • приносить ответ вместе с ходом проверки; • показывать лабораторные работы, отчеты, схемы и разобранные ошибки; • участвовать в сообществах и задачах, где видна командная работа; • поддерживать профессиональные связи и просить содержательную обратную связь; • фиксировать опыт так, чтобы его можно было объяснить другому человеку.

Инженер останется. Но профессия станет почти неузнаваемой

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

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

ПРАКТИКА НА БЛИЖАЙШИЕ 90 ДНЕЙ • выбрать одну реальную рабочую задачу и встроить ИИ в ее безопасный цикл, сохранив проверку и откат; • начать журнал решений: контекст, гипотеза, действие, результат, вывод; • изучить один соседний технологический слой, связанный с вашей основной специализацией; • описать для своей инфраструктуры пять действий, которые агенту нельзя выполнять без подтверждения; • провести разбор одной старой ошибки и превратить вывод в правило или тест.

Когда меня спросили, останется ли профессия инженера через пять лет, я ответил: останется, но станет почти неузнаваемой. Граница между ИТ, ИБ, эксплуатацией и архитектурой станет менее жесткой. Рутинные операции перейдут к автоматизированным системам. Инженер будет управлять определенным слоем результата.

«Профессия инженера останется, но станет почти неузнаваемой».

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

Спираль «я - мы - я - мы» продолжит раскручиваться. Первое «я» решало задачу собственными руками. Первое «мы» справилось с ростом сложности через специализацию. Новое «я» получает силу за счет моделей и агентов. Новое «мы» объединит людей и машины вокруг критической функции и общей ответственности.

Поэтому ИИ не отменит инженера. Он ускорит исчезновение инженера по инструкции.

И у меня остается открытый вопрос, который я предложил аудитории в финале вебинара: какая инфраструктура и какой подход к ее управлению ждут нас в мире, где рядом с человеком постоянно работают агенты? Ответ еще формируется. Но уже понятно, что его будут создавать те, кто умеет одновременно видеть атомы системы, понимать ее назначение и собирать новое «мы».

Смотреть полную видеозапись разговора: YouTube