Будущее ИТ и что в нём делать разработчику

Привет, Хабр! Я — Руслан, а это — моя статья написанная в основном по следам моего доклада про будущее ИТ, ИТ-архитектуры и работы айтишников + часть мыслей дооформилась после участия в подкасте (все ссылки в конце).

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

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

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

---

Что такое ИТ-архитектура — по-настоящему, а не последние 5-10 лет

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

Одно из моих любимых определений — из стандарта ISO:

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

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

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

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

А теперь, внимание, вопрос.

Зачем паттерны, если ИИ читает лапшеобразный код почти без проблем?

Итак, если нет цели читать код человеку…

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

Провокационный вопрос: а зачем нам тогда вообще языки программирования?

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

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

Примеры из других областей

AlphaGo vs AlphaZero. Сначала была нейросеть AlphaGo, которую обучили играть в шахматы (после игры Го) на миллионах человеческих партий. Она разнесла все шахматные движки. А потом сделали AlphaZero — практически ту же сеть, только без единой человеческой партии в обучении. И AlphaZero разгромила AlphaGo. Потому что в ней не было тех стереотипов, которые человечество накопило веками: как надо играть дебют, какие ходы интуитивно кажутся правильными… Освободили от человеческого опыта — получили скачок качества.

Google Translate. В какой-то момент Гугл разрешил своей сети-переводчику переводить не «с русского на английский» напрямую, а через внутренний промежуточный язык — свой собственный, математический, нечитаемый. Сначала с русского на «внутренний», потом с «внутреннего» на английский. И качество перевода рвануло.

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

Когда я первый раз рассказывал это внутри компании — некоторые разработчики испугались. Для меня же это отличная новость. Отличная! Потому что ещё больше рутины уйдёт, а нам достанется человеческая работа. Не нужно будет в сотый раз писать парсер Excel-файлов. Представьте, сколько миллиардов человеко-часов в мире тратится на примерно одно и то же только потому, что фреймворки не оптимальны и универсального парсера Excel у нас нет.

Истинное предназначение архитектуры

Хорошо, архитектура кода, допустим, не нужна. Но архитектура — это же далеко не только архитектура именно кода.

Что из этого уже переходит в автоматизацию

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

Архитектурные метрики. Тема, про которую я писал и выступал уже невероятно много — метрики архитектурного долга, тестирование архитектуры as Code, принцип каскадного снижения связанности (ссылки выше), — вдруг стала в разы актуальнее. Собирать метрики стало заметно проще, а их важность взлетела (т.к. писать код ИИ-агентами стало относительно дёшево и быстро, принятие архитектурных решений стало ещё более ответственным делом). То, что раньше жило в голове архитектора на уровне «ну вроде паттерн не нарушен», теперь без особых усилий проверяется тестами и ложится в цифры.

У меня на эту тему есть отдельный опенсорсный проект — AACT (Architecture as Code Tools: https://github.com/Byndyusoft/aact), — если интересно копнуть глубже.

Даже если не все паттерны мы пока можем покрыть детерминированными тестами — как минимум можно попросить ИИ проанализировать соответствие тому или иному принципу проектирования. В целом, сейчас можно “тестировать” практически всё что угодно (об этом тут).

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

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

И ещё один полезный чек-лист — границы применимости ИИ в архитектурных решениях:

• выбор технологии — ИИ справляется уже сейчас;

• декомпозиция системы — справляется с оговорками, в зависимости от сложности;

• верхнеуровневая абстракция и принципы — пока нет, эта работа остаётся человеку.

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

Средовой подход

Но если совсем далеко заглянуть, лет на 10-15 вперёд, — ИИ рано или поздно сможет и проектирование архитектуры взять на себя.

На мой взгляд, следующий этап развития ИТ — это переход от системного подхода к средовому.

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

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

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

ИТ пойдёт туда же. Мы перестанем думать категориями «300 микросервисов, между ними такие-то связи» и начнём думать категориями «вот эта штука ведёт себя по определённым законам, а внутри — рой чего-то, нам это не важно». И архитекторы будущего будут описывать методологию построения таких сред. Это большой новый вызов.

Пока это фантастика. Но лет через 10-15 — уже, возможно, и нет.

С.Б. Переслегин кратко о системном, средовом и сферном подходах: https://www.youtube.com/watch?v=Rn50DfXpATs

Что происходит с ролями в ИТ прямо сейчас

Вернёмся из дальнего будущего в ближайший год.

Грань между разработчиком, аналитиком и архитектором уже сейчас стирается. Раньше system design требовался на собеседовании только для сеньоров. Сейчас, если ты хочешь быть хорошим мидлом, ты уже обязан понимать, как система работает целиком. И это будет только усиливаться.

В новой картине мира:

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

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

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

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

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

Как работать с ИИ: чуть-чуть тимлид, чуть-чуть оператор

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

Главное — перестроить мозг. Когда ты сам пишешь код и когда командуешь ИИ — это две разные работы, и это гораздо больше похоже на работу тимлида. Ты:

1. Декомпозируешь задачу.

2. Формулируешь её.

3. Планируешь, что делаешь сам, а что делегируешь.

4. Делегируешь.

5. Ревьюишь и верифицируешь результат.

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

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

Третье — не работайте с ИИ через чат. Когда ты задаёшь вопросы в чате, ты каждый раз перегружаешь контекст заново. Либо сразу грузи в чат несколько файлов и ссылки и прямо проси внимательно изучить, либо используй полноценные инструменты (ИИ-агенты), где ИИ находится в курсе всего проекта, а не только твоего единичного вопроса. Это и есть та самая работа контекстом, про которую выше. Результат получается на порядок лучше.

Четвёртое — верификация. Если код пишет ИИ, то тесты должен писать человек. Слишком самонадеянно: «ИИ написал код, ИИ написал тесты, я проглядел одним глазом — поехали в прод». Для критичных задач — точно нет. Если объём большой и руками не потянуть, хотя бы возьмите разные модели либо разные архитектуры сетей, чтобы они проверяли друг друга. Идеального ничего не будет. Недавно попался любопытный замер на эту тему — LLM-сгенерированные навыки для агентов ухудшают выдачу, а навыки, написанные человеком, улучшают её примерно на 16%. Цифра хорошо объясняет, почему человек в цикле всё ещё нужен.

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

Шестое — ломайте вежливость модели. Маленький, но рабочий приём. Фраза «это архитектура двоечника, найди все проблемы» работает на порядок лучше, чем «проверь, пожалуйста, всё ли ок в моём решении». Модели по умолчанию вежливые и склонны соглашаться с тем, что им дали. Лёгкая провокация в промпте снимает эту вежливость и часто вытаскивает реальные проблемы, которые в нейтральном диалоге модель бы замяла.

Что конкретно делать уже сейчас

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

Сдвиг 1: борьба со сложностью вместо производства кода

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

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

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

• Настрой один архитектурный автотест — через AACT, ArchUnit, кастомный линтер, что угодно. Одно правило, одна проверка в CI, но уже работающая. Это проще, чем кажется 🙂

• Оцени свою текущую работу: у тебя на работе ценят архитектурные решения и борьбу со сложностью или только скорость закрытия задач? Если только скорость — начинай плановый переход. Это серьёзный сигнал.

Сдвиг 2: ИИ как новый режим мышления

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

• Проведи эксперимент «анти-чат»: загрузи полный контекст проекта плюс цель бизнеса, а не отдельный вопрос. Сравни с тем, что получалось через обычный чат. Разница обычно огромная.

• Напиши свой первый agent skill. Ещё полгода назад, чтобы встроить собственный экспертный опыт в агента, нужно было поднимать векторную базу, знать что такое чанки и эмбеддинги. Сегодня — текстовый файл с инструкциями в нужном формате, и всё. Возьми одну свою типовую задачу и оцифруй её. Маркетплейсы скиллов уже есть — skillsdirectory.com, skills.sh, clawhub.ai.

• Разбери три свои типовые задачи и определи: где рутина (→ агенту), где решение (→ мне), где проверка (→ обязательно мне).

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

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

Сдвиг 3: ответственность за результат, а не за код

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

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

• Собери чек-лист верификации ИИ-артефактов для своей предметной области. Код пишет ИИ, проверяет человек.

• Пройди один pet-project через SDD-инструменты — Spec Kit, Kiro или Open Spec. Встань в роль верификатора, не разработчика, и посмотри своими глазами, где LLM-спецификации начинают накапливать ошибку. Это тот самый опыт, который словами не передашь.

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

• Перепиши своё резюме вокруг решений, целей и результатов, а не стека технологий. Сделай один публичный артефакт end-to-end работы через ИИ — пост, статью, репозиторий, что угодно. Невидимая компетенция не ценится.

• Проведи один пилот безопасного внедрения ИИ на ограниченном процессе в команде, замерь скорость и ошибки, зафиксируй правила и антипаттерны. Роль проводника ИИ в организации — это роль, за которую уже платят, в отличие от роли «ещё один prompt-оператор».

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

Стратегические ставки, гипотезы и задачи в виде связанной карты можно посмотреть здесь: https://app.sociotech.center/projects/public/133b2a7b-c7b0-4559-8fe6-1b734e5085b1

За подробностями и/или если хотите присоединиться к редактированию данной стратегии выживания усиления своих компетенций в век ИИ — welcome!

И немного честности про инструменты сейчас

На сегодняшний день те же ИИ-инструменты для проектирования архитектуры — пока слабоваты. Я пробовал загружать простые ТЗ (условно — «система тайного покупателя для проверки качества сервиса в отеле»), и современные модели выдают что-то похожее на правду, схемы, четыре страницы текста, вроде даже PlantUML получается. Но присматриваешься — там висящие в воздухе стрелки, одна общая база данных, к которой ходят все микросервисы подряд, и так далее.

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

Ещё один свежий пример того же — Spec-Driven Development и инструменты вокруг него (Spec Kit, Kiro, Open Spec). Идея отличная, реализация пока сыровата. Я ставил эксперимент со Spec Kit: дал ТЗ, дальше почти не вмешивался. MVP получил за четыре дня. Последние два, правда, вычищал баги уже руками. Главный вывод для себя такой: спецификации, которые LLM генерит сама для себя, без человека в цикле начинают накапливать ошибку как снежный ком. Где-то это ломается раньше, где-то позже, но ломается.

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

Важно, что «пока».

Подведём итог

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

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

Важно:

• следить за инструментами и не отставать;

• уметь их использовать и адаптировать под себя;

• понимать не только возможности, но и ограничения;

• перестраивать мозг быстрее, чем перестраивается индустрия.

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

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

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

• Радость! Я ленивый, и чем меньше мне делать своими руками, тем радостнее.

• Азарт — мы сможем делать более сложные проекты, браться за задачи, которые раньше были в принципе нерешаемыми.

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

До будущего дожили. Нам с вами повезло вот ) 💜

Обещанные ссылки

• Запись доклада: https://rutube.ru/video/d3676fc6e26626c7f99f1faa877f05fc/

• [AI Dev подкаст #1] Проектирование систем в эпоху ИИ / Максим Смирнов, Руслан Сафин, Андрей Бураков: https://www.youtube.com/watch?v=IQ6zFeYDXd8

• Мой телеграм-канал Архитектура распределённых систем: https://t.me/rsa_enc