Привет, Хабр! Я — Руслан, а это — моя статья написанная в основном по следам моего доклада про будущее ИТ, ИТ-архитектуры и работы айтишников + часть мыслей дооформилась после участия в подкасте (все ссылки в конце).
Если предыдущие мои доклады и статьи были максимально ориентированы на практику —гранулярность микросервисов,каскадное снижение связанности,проектирование отказоустойчивости,покрытие архитектуры тестами— то здесь я сознательно отхожу в сторону и попробую пофантазировать и порассуждать о дальнем горизонте, а также построить стратегию и дать советы всем нам, что делать в наступающей эпохе ИИ.
Почему это важно? На конференциях мы постоянно обсуждаем ответы: как сделать микросервис, как спроектировать отказоустойчивость, какой брокер выбрать. Но мы почти не говорим о нерешённых и, тем более, о непоставленных задачах. Мы не обсуждаем будущее. Мы не обсуждаем вопросы, которые ещё не заданы. А чтобы задача поставилась, нужно как минимум о ней задуматься.
Но закончим с лирикой. Говоря о будущем ИТ, начнём, пожалуй, с ИТ-архитектуры — как дисциплины, описывающей базовые построения любого ПО.
Что такое ИТ-архитектура — по-настоящему, а не последние 5-10 лет
Чтобы рассуждать о будущем архитектуры, нужно сначала договориться, о чём мы вообще говорим. Архитектура как дисциплина — штука достаточно древняя, ей уже более полувека. И у неё есть сиюминутные назначения (читаемый код, поддерживаемый монолит, разнесение на микросервисы), а есть — истинное предназначение. И я сейчас про второе.
Одно из моих любимых определений — из стандарта ISO:
Архитектура — это фундаментальная организация системы, воплощённая в её компонентах, их отношениях между собой и с окружением, а такжепринципы, определяющие её конструкцию и развитие.
Для меня тут ключевое — «принципы, определяющие конструкцию и развитие». Архитектура — это не диаграмма и не картинка, это скорее стратегия и философия проекта. То, почему он сделан так, а не иначе, и как он будет жить дальше.
Одна из задач архитектуры сегодня — особенно если говорить про монолиты — это читаемость кода. Есть хорошая цитата Мартина Фаулера:
> Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Иногда смотришь на свой собственный код двухмесячной давности и уже не понимаешь, что ты имел в виду. Архитектура как раз призвана помочь тому, чтобы мы могли работать в командах, передавать код друг другу, уменьшать хрупкость, снижать количество багов. Все паттерны, вся теория последних тридцати-сорока лет были направлены именно на читаемость и поддерживаемость кода.
А теперь, внимание, вопрос.
Зачем паттерны, если ИИ читает лапшеобразный код почти без проблем?
На мой взгляд, через 2–4 года максимум ИИ будет писать хороший код. Не «генерировать фрагменты», которые потом доделывает человек, а полноценно писать рабочий код по текстовому описанию требований. Сейчас он ещё спотыкается — баги, уязвимости… иногда такую фигню выдаёт, что хочется закрыть ноутбук. Но это не горизонт дальнего будущего. Это ближайшие 2–4 года.
И когда это случится, возникает неудобный вопрос: зачем все эти паттерны, которые мы проходили на собеседованиях? Если для ИИ лапшеобразный, нечитаемый код — не проблема, если он по требованиям пишет код, а потом по изменённым требованиям спокойно разбирается в своей же лапше и всё без багов доделывает… то получается, что вся наша борьба за читаемость решает задачу, которой больше не существует.Да, ИИ и сам лучше “поймёт” хороший код, чем плохой. Но может только потому, что он сам обучен (пока) на наших паттернах, и лишь временно унаследовал понимание “хорошести” кода и человеческий способ его “чтения” и “понимания”? Но об этом чуть ниже
Итак, если нет цели читать код человеку...
Мы же не лезем сейчас в ассемблер и не проверяем, правильно ли компилятор соблюдает паттерны на уровне машинных команд. Скоро то же самое произойдёт с кодом. Он станет таким же внутренним слоем, как ассемблер сегодня.
Провокационный вопрос: а зачем нам тогда вообще языки программирования?
Ответ не такой очевидный, как кажется. Все наши языки — Python, Java, C#, Kotlin — создавались не для компьютера. Они создавались для нас с вами, для белкового мозга, чтобы человеку было удобно упаковывать сложность, заворачивать свои мысли и передавать их на исполнение процессору. Компьютеру они не нужны. Он мыслит математикой.
Сейчас ИИ программирует на тех же языках, на которых его обучали. Это переходный этап. Но если посмотреть в том числе по аналогиям из других сфер — скорее всего, это не навсегда.
Примеры из других областей
AlphaGo vs AlphaZero.Сначала была нейросеть AlphaGo, которую обучили играть в шахматы (после игры Го) на миллионах человеческих партий. Она разнесла все шахматные движки. А потом сделали AlphaZero — практически ту же сеть, только без единой человеческой партии в обучении. И AlphaZero разгромила AlphaGo. Потому что в ней не было тех стереотипов, которые человечество накопило веками: как надо играть дебют, какие ходы интуитивно кажутся правильными… Освободили от человеческого опыта — получили скачок качества.
Google Translate.В какой-то момент Гугл разрешил своей сети-переводчику переводить не «с русского на английский» напрямую, а через внутренний промежуточный язык — свой собственный, математический, нечитаемый. Сначала с русского на «внутренний», потом с «внутреннего» на английский. И качество перевода рвануло.
На мой взгляд, то же самое произойдёт с языками программирования. Да, если захочется — мы сможем попросить перевести «вот эту штуку на Python, чтобы я посмотрел». Но реально выполняться будет что-то другое: нолики-единицы, команды процессора, может быть — чистая математика. Python и его собратья — это костыль для нас, людей, чтобы формализовать абстрактность вычислений в удобную для белкового мозга форму. ИИ этот костыль не нужен.
Когда я первый раз рассказывал это внутри компании — некоторые разработчики испугались. Для меня же это отличная новость. Отличная! Потому что ещё больше рутины уйдёт, а нам достанется человеческая работа. Не нужно будет в сотый раз писать парсер Excel-файлов. Представьте, сколько миллиардов человеко-часов в мире тратится на примерно одно и то же только потому, что фреймворки не оптимальны и универсального парсера Excel у нас нет.
Истинное предназначение архитектуры
Хорошо, архитектура кода, допустим, не нужна. Но архитектура — это же далеко не только архитектура именно кода.
На мой взгляд, истинное предназначение архитектуры — этоборьба со сложностью и её укрощение. Любой проект убивает только одно — нарастающая сложность. И наша задача как архитекторов — с ней бороться (а ни в коем случае не примыкать к ней).
Смотришь иногда на разные «архитектурные решения» и думаешь: блин, ты же ей только услужил: туда гейтвей засунул, сюда ещё один слой абстракции, сверху накрыл событийной шиной, и теперь сложность ты не уменьшил, а аккуратно замаскировал её рост, замёл под ковёр.
Только борьба со сложностью позволяет подняться на следующий уровень. Позволяет коммуницировать, проектировать новое и большее — человеческий мозг не может удержать даже двадцать строчек кода, а вот схему поймёт, и собеседник с высокой вероятностью её же поймёт плюс-минус так же. Схематизация в таком случае — как раз способ борьбы со сложностью (точнее с тем, что мы текст воспринимаем хуже, чем зрительный образ (кстати в отличие от LLM)).
Про борьбу со сложностью у меня есть отдельная статья, если интересно — отсылаютуда. Здесь зафиксирую только одно: борьба со сложностью нужна на всех уровнях. Инфраструктура, микросервисы, бизнес-процессы — везде нужна визуализация. BPMN-схема бизнес-процесса, карта взаимодействий сервисов, граф зависимостей модулей. Человек работает с визуальной информацией, а не с конфлуенсом и таблицами на 400 строк.
Так вот: на мой взгляд, архитектура распределённых систем, архитектура взаимодействий, вот эта самая борьба со сложностью — ближайшие несколько лет точно останется за человеком, а не за ИИ.
Если раньше соотношение было такое: «разработка — это много работы, архитектура — это чуть-чуть по времени но сложной и ответственной, и архитекторы немножко смотрели на разработчиков сверху», то скоро маятник качнётся в другую сторону. Архитектура станет основным полем деятельности людей, которые создают софт. А разработка — то есть написание кода — уйдёт инструменту и будет занимать меньше человеческого времени.
Мы просто прыгнем на следующий уровень сложности процессов и результатов своей деятельности.
Что из этого уже переходит в автоматизацию
Пока большой вызов с проектированием будущих огромных распределённых систем остаётся впереди, частью работы архитектора уже прямо сейчас можно делиться с машиной — и это, на мой взгляд, отдельная радостная новость.
Архитектурные метрики.Тема, про которую я писал и выступал уже невероятно много — метрики архитектурного долга, тестирование архитектуры 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, примеры, стиль-гайды, бизнес-цель, ограничения — всё, что ты подсовываешь модели до того, как она начнёт думать. Формулировать научились почти все. Собирать контекст — навык, который только формируется, и именно он начинает отличать человека, получающего полезный результат, от человека, получающего правдоподобную фигню.
Как работать с ИИ: чуть-чуть тимлид, чуть-чуть оператор
Пара советов, которые я сам пробовал и которые, на мой взгляд, работают.
Главное —перестроить мозг. Когда ты сам пишешь код и когда командуешь ИИ — это две разные работы, и это гораздо больше похоже на работу тимлида. Ты:
- Декомпозируешь задачу.
- Формулируешь её.
- Планируешь, что делаешь сам, а что делегируешь.
- Делегируешь.
- Ревьюишь и верифицируешь результат.
Если ты был хорошим тимлидом — скорее всего, ты будешь хорошим погонщиком ИИ. И наоборот: если ты всю жизнь писал код сам и никогда никому ничего не делегировал, тут придётся учиться.
Второй момент —осознанность. В повседневной работе не так просто разделить, где рутина (её точно можно уже сейчас отдать машине), а где творчество и принятие решений (это оставляешь за собой). Но именно этот навык — отделять рутину от решения — нам всем скоро пригодится.
Третье —не работайте с ИИ через чат. Когда ты задаёшь вопросы в чате, ты каждый раз перегружаешь контекст заново. Либо сразу грузи в чат несколько файлов и ссылки и прямо проси внимательно изучить, либо используй полноценные инструменты (ИИ-агенты), где ИИ находится в курсе всего проекта, а не только твоего единичного вопроса. Это и есть та самая работа контекстом, про которую выше. Результат получается на порядок лучше.
Четвёртое —верификация. Если код пишет ИИ, то тесты должен писать человек. Слишком самонадеянно: «ИИ написал код, ИИ написал тесты, я проглядел одним глазом — поехали в прод». Для критичных задач — точно нет. Если объём большой и руками не потянуть, хотя бы возьмите разные модели либо разные архитектуры сетей, чтобы они проверяли друг друга. Идеального ничего не будет. Недавно попался любопытный замер на эту тему — 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
