Привет, Хабр! Эта статья — часть серии к 25-летию SpaceWeb. Раз в две недели берем спорный вопрос про будущее хостинга и инфраструктуры и зовем двух-трех экспертов, которые смотрят на него по-разному.
Сегодня спорим о том, способен ли ИИ придумать архитектурное решение, которого раньше не было. Виталий считает, что способен. Алексей отвечает, что система, которая кормится готовыми знаниями, ничего не изобретет с нуля.
В каждой статье серии спрятан артефакт: секретное слово, ответ на вопрос или факт о компании. Собирайте их по ходу серии. 4 сентября, в день рождения SpaceWeb, откроется форма, куда нужно будет внести все найденное. Чем больше артефактов соберете, тем выше шанс попасть в число победителей и забрать набор мерча. Хештег серии: #spaceweb25лет.
Навигация по тексту:
Участники разговора
Виталий Киреев, руководитель исследований и разработки SpaceWeb. Больше 20 лет в ИТ, основной опыт — веб, базы данных, ИИ и highload-системы.
В начале разговора Виталий сразу сделал оговорку: «Я не адепт искусственного интеллекта и не считаю, что сейчас ИИ заменит всех программистов. Но я считаю, что ИИ точно повысит производительность труда ИТ-специалистов».
Алексей Шашкин, коммерческий директор SpaceWeb. В ИТ и телекоммуникациях с 2006 года. В разговоре смотрит на тему со стороны бизнеса и владельца продукта.
Проектировать умеет, вопрос в том, кто принимает работу
ИИ уже пишет Terraform и разбирает логи. А проектировать он умеет?
Виталий Киреев
Умеет, и умеет достаточно хорошо.
Свежий пример: мы сделали почасовой биллинг. Хорошее архитектурное решение, и сделали мы его без ИИ — прошли все классические шаги, собрали технические требования, выбрали технологии, построили архитектуру. Прошли через тернии и получили неплохой результат. А после этого решили сделать аудит решения с помощью ИИ.
Он предложил несколько вариантов. Мы приземлили их на свои технологии, со своими ограничениями и предварительными установками. Кроме аудита уже существующей архитектуры у нас есть и кейсы с новыми решениями. Например, разделение фронтенда и бэкенда крупного проекта. Там мы полностью опирались на то, что предложил ИИ.
А если у архитектора нет времени писать подробное ТЗ?
Виталий Киреев
Есть несколько уровней детализации задания.
Первый — концептуальный. Мы не знаем, какие есть подходы к задаче, и спрашиваем: какие вообще существуют архитектурные паттерны, что можно порекомендовать. После этого формулируется высокоуровневая архитектура: какие будут узлы, какие слои, как они взаимодействуют, какие технологии могут использоваться.
Дальше можно конкретизировать. Если работать через агента, он подразумевает пошаговую работу: мы получаем ответ, агент задает уточняющие вопросы, и мы либо уходим глубже в какую-то область знаний, либо приземляем решение на свои технологии. Таким интерактивным способом можно от общего спуститься до конкретной реализации.
Второй подход — написать максимально подробное ТЗ, агентский файл, инструкции. Архитектор проходит все шаги у себя в голове: понимает, какую архитектуру хочет, какой стек. Наверняка есть техрадар, на который он опирается. Все это излагается подробно, и тогда ИИ выдаст максимально конкретное решение сразу.
Я не скажу, что один подход лучше другого. Под каждую конкретную задачу можно использовать либо один, либо второй, либо как-то их миксовать.
Алексей Шашкин
Проектировать, конечно, умеет, тут Виталий прав. Но вопрос в другом: кто принимает этот проект? Кто ставит задачу и кто на выходе оценивает результат?
Здесь надо смотреть, на каком уровне развития находится бизнес и на каком уровне находится проект. Когда я сам себе бизнесмен и сам представляю, что должно получиться на выходе, ИИ-архитектор отлично справится. У меня есть видение, я готов получить какой-то результат и понимаю, как поставить задачу.
Когда речь про зрелую компанию, где много зависимостей и много стейкхолдеров, важно понимать, кто задачу ставит, кто ее принимает и кто гарантирует, что созданная архитектура будет соответствовать требованиям, ожиданиям и бюджету.
Так что если коротко: да, умеет. Но кто отвечает за этот процесс — это очень важно.
Контекст, который в агента не загрузишь
Проектирование наполовину состоит из ограничений: бюджет режут, сроки горят, половина команды не видела Kubernetes. С этим ИИ что-то может?
Виталий Киреев
Если говорить про технологичность, то есть про то, что команда знает, а чего не знает, — здесь ИИ может погрузиться очень глубоко. Для этого есть техрадар, где мы описываем технологии, которые уже используются в проекте, которые знает команда, которые перспективны и от которых мы хотим избавиться. Этот техрадар вполне может составлять основу технического задания.
Если же говорить о ресурсах, бюджете, сроках, проблемах команды — наверное, это тоже можно как-то отобразить в ТЗ или стандартизовать. Но я не видел какого-то примера, где это сделано хорошо.
Кажется, что эта зона ответственности все же должна лежать на человеке, который контролирует то, что предлагает ИИ. Потому что решение может быть замечательное, но дорогое. Может быть технологичное, но выходящее за рамки компетенции команды. Может ли ИИ что-то с этим сделать? Наверное, да. Может ли он сделать это лучше, чем человек, который погружен в команду и знает особенности бизнес-процессов компании? Скорее нет.
Алексей Шашкин
Самая главная история в том, что на данном этапе физически невозможно загрузить агенту весь объем контекста, который известен ответственному лицу.
Речь не только про технологии и стеки. Речь про текущую ситуацию, про то, как она может развиваться завтра, какие есть отношения в команде, какие риски. Огромное количество нестабильных переменных, которые продвинутый архитектор или разработчик знает просто потому, что варится в этом контексте каждый день.
Передать все это можно. Но сколько это потребует времени и как часто нужно будет этот контекст обновлять? Вот это и ставит ИИ в более уязвимую позицию, чем живого человека, который каждый день работает и обладает всеми связями.
Типовое против прорывного
Скептики скажут: ИИ посмотрел на тысячу похожих систем и выдает среднее по больнице. А проектировать приходится как раз тогда, когда типовое не подходит.
Виталий Киреев
Вот здесь я поспорю с самой формулировкой. Проектировать приходится тогда, когда типовое не подходит — на самом деле нет.
Из опыта могу сказать: подавляющее большинство архитектурных решений, которые применяются в разработке в обычной компании, типовые. Я сейчас не говорю про полет на Марс или про изобретение лекарства от рака.
И ИИ как раз позволяет команде не изобретать велосипед каждый раз. Команда не знает этих тысяч решений и тысяч кейсов. Она получает задачу, ей кажется, что надо спроектировать что-то свое, чего никто до этого не делал, и начинается дорогая разработка решения, которое по сути уже существует.
ИИ кратно повышает производительность, потому что ориентируется на решения, которые уже доказали свою эффективность. Я бы даже наоборот сказал: не всегда нужно использовать индивидуальный подход к решению. Можно выбрать готовое, и это будет дешевле и эффективнее.
Но и задачи, которые действительно нетиповые, мы не исключаем. И здесь ИИ со своим бэкграундом реализованных проектов может и не сгенерировать прорывную идею. Но как минимум он покажет, что уже есть. И на основании этого архитектор или команда сможет придумать то самое нестандартное решение.
С другой стороны, ИИ видел больше архитектур, чем любой из нас увидит за карьеру. И может притащить решение из финтеха в ритейл. Разве это не преимущество?
Виталий Киреев
Здесь мы затрагиваем очень важную тему. Специалист, например, в ИТ-сфере имеет очень глубокую компетенцию, область знаний у него глубоко проработана. Но при этом он слабо понимает процессы, которые есть, скажем, в строительстве.
И тут есть интересный кейс. Мы можем описать свою систему в виде здания: что у нас фундамент, что стены, что двери. И задать вопрос: как защитить эту архитектуру от землетрясения?
В этом случае ИИ может предложить решение, которое эффективно используется в одной сфере, но не свойственно предметной области, в которой мы спрашиваем. Дублирование, резервирование.
Алексей Шашкин
У меня здесь две противоположные точки зрения.
Начнем с первой. Мне как бизнесу, конечно, интересно получать быстрое работающее проверенное решение.
Но с другой стороны, мне как бизнесу, который работает в быстро растущей области, полной инноваций, и одновременно как инженеру иногда кажется, что не всегда простое и распространенное решение — это круто. Оно может быть чрезмерно сложным, чрезмерно общим, покрывающим кучу разных вариантов.
Мой отец, тоже очень хороший инженер, говорит: хороший инженер знает, что нужно делать, а отличный инженер знает, чего делать не нужно. Иногда хочется получить от архитектора ответ не «нам нужен Кубер, микросервисы и куча баз данных», а «нам здесь хватит тупого монолита, одной базы данных, одного сервера, и больше ничего не надо, потому что я не вижу необходимости».
Вот этот самый интеллект отличает потрясающих специалистов от средних по рынку, на которых как раз равняется нейросеть. И именно в этой разнице может крыться невероятная экономия или суперскорость запуска новых продуктов, когда человек способен отказаться от лишних технологий и лишних заморочек. А ИИ нет, потому что на рынке так принято, так уж здесь повелось.
То же самое касается ширины кругозора. Да, это преимущество по ширине. Но я не уверен, что это преимущество по глубине. Находить вот эти связи между разными областями знаний, которые людям приходят иногда во сне, ИИ пока не способен, потому что это система, которая кормится за счет уже существующих знаний, а не изобретает их с нуля. В хорошем смысле изобретает.
Здесь, мне кажется, и кроется самая большая ценность человека: посмотреть на задачу свежим взглядом и найти решение, которого никто еще не видел. Потому что взгляд не замылен одинаковыми решениями.
Виталий Киреев
Чуть-чуть дополню Алексея. У ИИ есть параметр, который влияет на генеративность, — температура. Он приводит к двум прямо противоположным эффектам.
Первый — галлюцинации, когда генеративная модель говорит то, чего нет. Второй — эволюционная составляющая.
Существует мнение, что качество предлагаемых ИИ решений будет усредняться дальше, и со временем будет всё хуже и хуже. На самом деле это не совсем так. За счет генеративной составляющей ИИ может сгенерировать то, чего еще не было нигде. Это как с генными мутациями: они могут быть в хорошую сторону, могут быть в плохую, плохие отсеиваются, хорошие закрепляются.
Здесь так же. ИИ предложил решение, которого еще не было. Архитектор посмотрел и сказал: да, это имеет смысл, такого никто не предлагал. Решение закрепили, оно вернулось через обратную связь в обучение будущих моделей, и они начали его использовать.
Благодаря этой петле обратной связи ИИ будет предлагать более качественные и более новые решения, которых до этого никто не предлагал.
Алексей Шашкин
Может быть. Но здесь есть две большие проблемы.
Во-первых, не всегда ИИ получит обратную связь о том, что придуманное им решение хорошее и работает. Либо это может занять продолжительный срок, пока он узнает об этом из внешних источников.
Вторая проблема: ИИ не будет думать об одной задаче днями, вечерами, неделями, пока однажды перед сном ему эта идея в голову не придет. Ты ему дал задачу, он покрутил, что-то выдал. А человеку ты можешь дать задачу, и он может думать над ней годами и найти решение. Либо не найти. Вот это очень большая разница между человеком и ИИ, которую, мне кажется, еще не все учитывают.
Ответственность остается на человеке
ИИ предложил схему, ее согласовали, через полгода все легло под нагрузкой. Кто виноват?
Алексей Шашкин
Здесь очень простой ответ. Между «так предложил ИИ» и «так написано в статье», «так написал вендор», «так было в книге» нет никакой разницы. Всегда ответственный — человек, в чьей зоне ответственности находится принятое решение.
ИИ не отвечает за сервер, не участвует в аварийном созвоне, не теряет клиентов, не объясняется с руководством и в принципе не меняет поведение после личной неудачи, как это делает человек. Поэтому любое архитектурное решение, которое никто из людей не способен защитить и проверить, нельзя считать согласованным.
Виталий Киреев
Я попробую сказать с другой стороны. ИИ может обосновывать свои решения и критиковать их.
Мы можем попросить его объяснить решение, то есть почему он его принял. Потом покритиковать: какие есть узкие места, какие спорные моменты, что можно улучшить. Это работает уже сейчас, эти инструменты используются.
Но что такое зона ответственности? Ответственность — это когда за наступление события есть последствия у ответственного лица. Какие последствия могут быть у ИИ? Ну, мы можем выбрать другую генеративную модель. Можем выключить сервер.
Исходя из этого понимаем, что все же должно быть лицо, принимающее решение. Не обязательно один человек, это может быть коллегия специалистов. И она должна верифицировать и подписываться под тем, что предложил ИИ и что в итоге получилось. Кто поддерживал решение, тот и будет ответственным за ситуацию.
Документация переживет всех
Через три года никто уже не помнит, почему выбрали именно такую схему. Если выбирал ИИ, спросить будет некого?
Виталий Киреев
Здесь есть хорошая практика, и я хочу, чтобы в статье это было прямо написано. Мы не просто даем задачу ИИ. Мы просим его по шагам объяснить, почему было принято такое решение. И отдельно просим проанализировать это решение, сделать его аудит, покритиковать.
Когда мы идем по шагам, мы можем оценить, на каком шаге ИИ подумал в неверную сторону, и скорректировать этот шаг. А когда он оценивает свое решение с точки зрения критика или аудитора, он подсвечивает моменты, которые мы могли пропустить. Например, говорит: вот здесь может быть уязвимость. И мы отвечаем: хорошо, что ты можешь предложить, чтобы убрать эту уязвимость, — и допиливаем решение.
Все это логируется в технической документации. И неважно, сколько лет прошло. Любая генеративная модель формирует планы, UML-диаграммы и все спецификации, которые входят в джентльменский набор документации по архитектуре. Все сохранится и поднимется, если через три или четыре года возникнут вопросы, почему было принято такое решение, как оно работает и какие были риски. Такие вопросы просто не будут возникать, если вы все делали по процессам, которые сейчас рекомендованы.
Алексей Шашкин
Я проще скажу. Спустя три-четыре года совершенно уже неважно, кто принял такое решение. И спросить за это все равно будет не у кого. Не в том плане, что этих людей уже нет. В том плане, что момент заигран, все принято разгребать теперь всем вместе. При текущей скорости развития компаний, технологий и продуктов это уже не имеет никакого значения.
Как мы используем ИИ сами
Вы сами ИИ при проектировании используете? И были ли неуспешные кейсы?
Виталий Киреев
Используем достаточно активно, именно в разрезе архитектуры, как помощника архитектора. Есть хорошие кейсы, которые мы проверили и внедрили.
Они основаны не только на RAG-системе и на решениях, которые ИИ предлагает для той или иной задачи. Это приземление этих решений на наш техрадар, на наши технологии, на описание структур хранения данных и связей между ними и даже на наш программный код, который специальным образом документируется.
Мы провели внутреннее исследование, которое показало: определенные особенности в нейминге, в комментариях, в связях, которые описываются в структурах данных и в объектной модели, позволяют сделать код максимально понятным для генеративной модели. Тогда решение, которое она предлагает, приземляется не только на наши технологии, но и прямо на наш код и на нашу структуру хранения данных.
Это не значит, что мы получили решение и тут же добавили его в релиз и выкатили на прод. Нет, конечно. Все проходит верификацию и тесты, и только после этого код, может быть даже в измененном виде, попадает в проект и уходит в релиз.
Но производительность команды это повышает значительно. Почему? Некоторые наши проекты достаточно большие, структуры данных тоже большие. Есть специальные модели, которые это все описывают, можно поднять и посмотреть. Но то, насколько быстро это делает ИИ, человеку недоступно. Какие таблицы, какие связи, какие модули, как они взаимодействуют, какие методы вызываются у каких классов. Это все ИИ обрабатывает в огромных масштабах за минимальное время. А человеку нужно много времени без гарантии, что он охватит все.
Что касается неуспешных кейсов, тут тема хайповая.
Я довольно часто сталкиваюсь с хейтом. Мне говорят: ИИ никогда не сможет залезть в наш проект и что-то сделать, это просто невозможно, проект очень сложный, нужно знать кучу тонкостей, там все так сильно взаимосвязано. Он генерирует какой-то код, и мы над ним смеемся: боже мой, какую чушь он сформировал.
А как только начинаешь смотреть на этот проект и на этот код как профессионал, видишь большое количество костылей. Код не задокументирован, методы выполняют не то, что должны, в одном методе несколько действий. Все те ошибки, которые влияют на качество кода, не позволяют модели эффективно с этим кодом работать.
Думаю, мы будем проходить какой-то переходный период, когда выстроим наш код и структуры данных максимально правильно. Не только для ИИ, а вообще по правилам чистой архитектуры и разработки. И тогда число неудачных кейсов будет стремительно падать.
То, что сейчас оно высокое, — не показатель того, что ИИ плохой. Это показатель того, что проекты, в которых пытаются его применять, недостаточно хороши. У нас тоже есть негативный опыт с легаси-проектами, где генеративная модель выдавала откровенную чушь. Просто потому, что сам проект содержал много сложных запутанных алгоритмов и костылей, в которых и обычному человеку тяжело разобраться.
Алексей Шашкин
Если коротко, с Виталием полностью согласен. Грубо говоря, мусор на входе — мусор на выходе. Чудес тут не бывает.
Про мой личный опыт: ИИ безумно упрощает жизнь. Я стал гораздо меньше ставить запросов разработке. Снял с них задачи по перевариванию информации из вида А в вид Б, все это автоматизировал для себя. Тем самым даю возможность команде Виталия заниматься непосредственно продуктом, а не моими аналитическими хотелками.
Были ли косяки? Наверное, были. Но чем больше я погружаю своего агента в контекст, в знания, в данные, в то, что мне от него нужно и как я хочу это видеть на выходе, тем ошибок меньше.
Коммуникация и организация процессов
Архитектор половину времени не проектирует, а договаривается с людьми. Эту часть ИИ заберет?
Алексей Шашкин
Думаю, да, это возможно. Технологически нет ничего сложного в том, чтобы научить агента опрашивать всех заинтересованных лиц в контексте задачи и получать от них точки зрения, ограничения, пожелания. Со временем это можно реализовать.
Но повторюсь: в любом случае бизнесу нужен будет человек, который отвечает за то, что на выходе получилось именно то, что бизнес ждет.
Виталий Киреев
У агентов сейчас много инструментов, в том числе коммуникационных. Они позволяют ходить в CRM, в планировщик, узнавать о свободных ресурсах, о планах, о задержках, генерировать инциденты и реагировать на них. Все это уже есть.
Но момент коммуникации непростой. Координация всех действий агенту сейчас доступна в меньшей степени, чем как человеку. Есть LangGraph, где можно запрограммировать определенные алгоритмы действий: если агент видит, что срок нарушается, или что произошла поломка, или что кто-то заболел. Но это все равно не покроет все кейсы.
Если резюмировать: на текущий момент ИИ точно не сможет заменить организацию всех процессов. А в будущем, наверное, да.
Алексей Шашкин
Добавлю, что важнейшее ограничение здесь не со стороны ИИ или агентов, а со стороны людей, которые готовы или не готовы переформатировать свое взаимодействие с системой.
Любые изменения требуют воли. Это может быть воля рынка, воля руководителя, воля клиентов. Но что-то должно заставить человека пересмотреть свое отношение ко взаимодействию со всей системой принятия решений. Сказать: ладно, не будем сейчас созваниваться, пускай ко мне приходит агент с чеклистом, я буду тыкать галочки или общаться с ним напрямую, и я полностью доверяю ему в том, что он правильно интерпретирует все мои слова.
Так не бывает, это тяжело. Большая часть людей настроена решать организационные вопросы давно принятыми методиками: собраться на совещание, обсудить, договориться, принять решение, зафиксировать. Включение сюда ИИ радикально меняет эти подходы, а доверия к этому пока нет. Взять и внедрить это за день не получится. Когда-то мы к этому придем, но это будет не завтра и не послезавтра.
Что будет с джунами
Архитектором становятся лет через десять после первой строчки кода, набив шишек. Джуны сейчас пишут с ИИ и шишек не набивают. Откуда возьмутся архитекторы?
Алексей Шашкин
Я не вижу здесь большой проблемы. Когда-то Ньютон придумал дифференциальное и интегральное исчисление, чтобы решить стоявшие перед ним математические задачи. Потом кто-то изобрел калькулятор, кто-то изобрел компьютер. Это всего лишь инструментарий, который помогает человеку решить поставленные задачи.
С искусственным интеллектом такая же история. Это просто инструмент, который помогает быстрее достичь результата. А правильный он или неправильный — зависит от того, что на входе. А на входе все равно формирует конкретный человек. Поэтому я не думаю, что этот вопрос имеет большое значение.
Виталий Киреев
Самый большой страх сейчас в следующем. Подавляющее большинство разработчиков стало использовать ИИ и генерировать код. Разработчик смотрит на этот код и в принципе знает, как он работает: он обучался, он писал сам, он может увидеть подводные камни и скрытые угрозы. И это срабатывает — сейчас есть специалисты, которые, посмотрев на код, понимают, что в нем не так.
А страшилка в том, что новое поколение не будет писать код самостоятельно, будет использовать генерацию и потеряет эту область знаний. Будет получать код, но не понимать, как он работает, и не понимать мест, в которых могут возникать ошибки. А это угроза безопасности либо неверная работа алгоритмов.
Я понимаю этих людей и на какую-то долю принимаю их позицию. Но мы все проходили переход к фреймворкам. У меня довольно большой опыт, и раньше все писали нативный код. Каждый программист владел десятью способами сделать сортировку списка. А потом все ушло во фреймворки, и была ровно такая же страшилка: люди разучатся писать код, будут просто вызывать нужную функцию, не зная, как она работает, и на этом наступит крах разработки.
Но этого не произошло. Почему? Изначально фреймворки действительно были дырявые, не все было гладко. А потом на петле обратной связи, на учете ошибок и проблем они подтянулись и стали достаточно безопасными. Сейчас выходят обновления, мы их постоянно актуализируем, но уже никто не осуждает человека за то, что он использует фреймворки.
Так вот представьте, что ИИ — тот же самый фреймворк, только универсальный. Он сможет предлагать вам все, что нужно, без вашего непосредственного участия и без вашей реализации. Конечно, сейчас в этих алгоритмах есть дыры и есть проблемы, с которыми сталкивается генерируемый код. Мы придем к моменту, когда уже не обязательно будет понимать, как работает каждая строчка, чтобы оценить, корректна она или нет.
Параллельно развивается направление критики. ИИ-критик анализирует то, что сделала генеративная модель, и это супер полезно. Тот код, который сейчас программист оценивает взглядом и думает «нет, этот код совсем не подходит, тут все плохо», будет просматриваться критиком, который намного глубже погружен в сферу и имеет за спиной даже не тысячи, а сотни тысяч багов и сотни тысяч решений, обычному программисту просто недоступных.
И вот эта связка позволит генерировать код, который будет использоваться. Джуну в тот момент уже не нужно будет знать особенности конструкций языка и реализации алгоритмов на том уровне, который нужен разработчику сейчас. Но ему точно нужно будет понимание фундаментальных принципов: объектно-ориентированного программирования, чистой архитектуры, хранения данных, алгоритмов и того, как технологии должны друг с другом взаимодействовать.
Компетенция джуна просто уйдет на уровень выше, не на уровень кода. Это будет уже разработчик, который принимает решения. Поэтому да, шишек в коде они сейчас не набьют, и это нормально. Их будет набивать критик искусственного интеллекта.
2036 год
У каждого бизнеса свой ИИ-архитектор или все та же ручная работа?
Алексей Шашкин
Любая нормальная компания будет максимально стремиться автоматизировать любую рутину, а создание архитектуры отчасти рутина. Архитектор должен оставаться — это человек, который решает, как формулировать ограничения, проверять допущения, управлять рисками, контролировать стоимость и сложность и добиваться организационного принятия решения. Но непосредственно ручная работа должна перейти к ИИ.
Виталий Киреев
Соглашусь с Алексеем и дополню.
Малый бизнес сейчас не может нанять архитектора, да и большую ИТ-команду тоже, потому что это дорого. А если все это будет становиться дешевле и доступней, мы получим колоссальный прирост производительности.
И здесь я хочу сделать маленький, но очень важный акцент. Люди думают, что ИИ будет конкурировать с текущими ИТ-компаниями, что мы будем грызть друг друга. Нет. ИТ просто будет уходить в те сферы, где сейчас представлено минимально. Я не говорю, что ИИ будет плести лапти, наверное, этого не произойдет. Но мы увидим ИТ в консалтинге, в аналитике, в личных помощниках. ИТ-сфера будет разрастаться в те области, где сейчас она есть только на уровне инфраструктуры: табличка Excel, какой-то компьютер, база 1С.
Поэтому я точно верю, что у каждого бизнеса будет какой-то ИИ-инструмент. И чем больше этих инструментов, тем эффективнее и производительнее будет работать бизнес. Архитектура и архитектурные решения в большей степени будут предлагаться ИИ, а не человеком.
Хотя смерть ручной работы я точно не прогнозирую. Та часть людей, которая сейчас генерирует идеи, никуда не денется, просто она будет генерировать их производительнее и масштабнее.
Что учить будущему архитектору
К вам пришел человек, который хочет стать архитектором. Что посоветуете учить?
Виталий Киреев
Обязательно фундаментальные знания, без этого никуда. Даже если мы говорим о современных ИИ-технологиях, это все 1950–1970-е годы прошлого века. Просто сейчас мы смогли добиться того, что нейронные сети раньше состояли из ста нейронов, а сейчас из ста миллиардов. Но от этого сами технологии не поменялись. Фундаментальные знания будут ценны всегда, тем более что математика опережает современную инженерию лет на 200.
Кроме фундаментальных знаний нужно смотреть стек современных решений, в том числе ИИ-решений, чтобы понимать, как правильно ими пользоваться. Постановка задач, объяснение решения, критика результата, документирование. В современных реалиях это просто необходимо знать. И вот на этой фундаментальной базе и современных технологиях вырастет специалист, который ответит всем современным вызовам.
Алексей Шашкин
Согласен. Информатику, матлогику, теорию сетей.
Чем закончилось
Эксперты спорили меньше, чем мы рассчитывали. Что проектировать ИИ умеет, сомнений не возникло. Ответственность оба оставили человеку, хотя пришли к этому с разных сторон.
Разошлись всерьез в одном. Виталий верит, что ИИ способен выдать решение, которого раньше не существовало. Алексей отвечает, что система, которая кормится готовыми знаниями, не изобретет с нуля, и добавляет: ИИ не станет думать над задачей неделями, пока однажды перед сном не придет ответ.
Кто прав, поймем сильно раньше 2036 года. Напишите в комментариях, какую свою задачу вы точно не отдали бы ИИ. Соберем самые интересные ответы для следующего текста серии #spaceweb25лет.
ссылка на оригинал статьи https://habr.com/ru/articles/1064758/