Инженер будущего: что стоит создавать и кто отвечает за результат

Сергей Авдейчик · DOBROVOLA · 25 сентября 2026 года

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

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

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

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

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

Код может написать агент. Инженером вместо вас он не станет.

Программа работает. Но нужна ли она кому-нибудь?

Самый неудобный вопрос в проекте часто звучит не «Как это сделать?», а «Зачем мы вообще это делаем?».

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

Для меня это не разговор о бизнесе вместо инженерии. Это начало инженерии.

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

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

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

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

Меняется не профессия целиком. Меняется её центр тяжести

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

Однако сам путь к результату меняется.

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

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

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

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

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

Открыть иллюстрацию в полном размере

Не ищите волшебный запрос. Стройте рабочий процесс

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

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

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

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

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

Цель здесь — не заставить человека наблюдать за каждым движением машины. Наоборот, я хочу освободить наше внимание для тех решений, где оно действительно необходимо. Хорошая организация позволяет не стоять над исполнителем. Плохая заставляет бесконечно спрашивать: «Ну что там? А точно готово?»

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

Чистый код — не роскошь для спокойных времён

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

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

Аккуратная структура не гарантирует отсутствия ошибок. Зато она даёт возможность предметно обсуждать систему. Где находится правило? Кто отвечает за этот участок? Что затронет изменение? Без такой ясности любая доработка превращается в разведку на чужой территории.

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

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

Осторожность становится инженерным качеством тогда, когда превращается в действие. До этого она остаётся правильным высказыванием.

Не стройте карьеру на том, чего модель пока не умеет

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

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

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

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

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

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

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

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

Три способа незаметно потерять самостоятельность

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

Кода становится больше, а понимания — нет

Это долг понимания. Программа растёт быстрее, чем ваша способность объяснить, как она работает.

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

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

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

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

Уверенность агента становится вашей уверенностью

Другая ловушка тише. Агент отвечает складно, приводит объяснение, предлагает план. И вы ловите себя на том, что уже согласились — ещё до того, как составили собственное мнение.

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

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

Если мнения совпали, это ещё не доказательство. Если разошлись — отлично, появилось место для исследования. Пусть спор разрешится проверкой, а не тем, кто увереннее пишет.

Агентов становится больше, а вас — нет

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

А ваше внимание осталось прежним.

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

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

Зрелое управление — не бесконечная переписка с исполнителями. Это устройство работы, при котором существенное не теряется среди сообщений о занятости.

Открыть иллюстрацию в полном размере

Ответственность — это не подпись в конце отчёта

Мне не близка мысль, что ответственность досталась человеку как остаток после автоматизации: всё интересное забрала машина, а нам оставили отвечать за ошибки.

Наоборот. Именно ответственность позволяет доверить системе больше работы.

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

Подпись под работой для меня означает не «я лично написал каждую строку». Она означает: «Я понимаю достаточно, чтобы объяснить принятое решение. Знаю существенные ограничения. Могу показать основания для доверия. И не исчезну, когда обнаружится проблема».

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

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

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

Между «сделано» и «можно выпускать»

Я разделяю работу на два связанных цикла.

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

Между этими циклами должно передаваться не слово «готово», а доказательство.

Открыть иллюстрацию в полном размере

Что именно изменилось? Какой сценарий проверен? На каких данных? Что получилось при ошибке? Можно ли повторить проверку? Что осталось за её пределами?

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

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

Моё рабочее правило здесь простое: не можешь объяснить существенное решение — не объявляй результат готовым.

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

Да, программированию всё ещё нужно учиться

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

Нет. Я хочу предостеречь вас именно от такого вывода.

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

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

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

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

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

Код остаётся языком профессии. Даже если вы не пишете каждую фразу, на этом языке нужно уметь читать, думать и спорить по существу.

На что я советую опираться

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

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

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

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

Проектировать проверку до получения ответа. Что подтвердит успех? С чем мы сравниваем? Какие данные нужны? Как выглядит неудача? Когда проверка появляется только после реализации, слишком легко подогнать её под то, что уже получилось.

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

Доводить дело до результата и беречь внимание. Законченная небольшая веха ценнее десятка одновременно начатых направлений. Умение сказать «это пока не готово» иногда полезнее способности быстро произвести ещё один убедительный отчёт.

Эти способности держатся друг за друга. Знание архитектуры не спасает ненужный продукт. Проверка не заменяет понимание цели. Хорошая идея не отменяет качества реализации. А ответственность без знаний рискует остаться красивым обещанием.

Зачем тогда нужны практика и диплом

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

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

В работе со студентами я опираюсь на последовательность: идея → блюпринт → техническое задание → проверяемые вехи → реализация → доказательства → приёмка и выводы.

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

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

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

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

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

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

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

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

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

Я не обещаю вам спокойной профессии

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

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

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

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

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

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

Для меня это и есть главный вопрос вашего образования.

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

С чего начать перед следующей встречей

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

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

Потом закройте чат и попробуйте рассказать о своей системе своими словами. Не идеально. Не как на конференции. Просто понятно.

С этого и начнём.

Об авторе и связь

Я — Авдейчик Сергей Валентинович, кандидат технических наук, AI/ML-инженер и разработчик прикладных ИИ-систем. В работе со студентами я соединяю исследование, проектирование, агентную разработку и проверяемый результат.

DOBROVOLA: dobrovola.dev/ru Электронная почта: chatwebmarket@gmail.com LinkedIn: sergei-audzeichyk GitHub: sergeionlyart

Для дальнейшего чтения

Эдди Османи — «The engineer of the future is the person who is able to choose what is worth doing». О выборе задач, делегировании и ответственности инженера. Схема двух рабочих циклов на рисунке 3 создана по схеме Эдди Османи.

Сергей Авдейчик — «Агент пишет код. А кто проектирует работу?». О том, как организовать агентную разработку вокруг замысла, вех и проверяемого результата.

Авторская позиция о подготовке студентов; не официальный регламент вуза. Иллюстрации созданы с помощью генеративной модели. Редакция от 25 сентября 2026 года.