Привет, Хабр!

«Программистов станет больше, но других» — эта фраза из недавней дискуссии в телеграм-канале Dev Q&A заставила меня задуматься о том, насколько быстро меняется наша профессия.

Коллеги из Диасофт — Сергей Ольков и Дмитрий Старов — вместе с экспертами из других компаний устроили жесткий разбор того, что происходит с разработкой в эпоху ИИ. К ним присоединились Дмитрий Маруськин (руководитель команды разработки ContentCapture, Контент ИИ), Дмитрий Демиркылыч (АО "Нейросети"), Сергей Сергеев (Comindware) и Алексей Граков (Agizo).

Сам я в дискуссии не участвовал, но внимательно следил за разговором — особенно за откровениями коллег о нашей внутренней кухне. Дмитрий Старов рассказал, как мы координируем работу 200 команд разработки через low-code платформу (спойлер: без «трактора» для тысячи микросервисов уже никак), а Сергей поделился реальными кейсами внедрения ИИ-инструментов — где взлетело, а где пришлось откатываться.

Самое ценное в дискуссии — полное отсутствие розовых очков. Алексей Граков прямо рассказал о сокращении 10 разработчиков после того, как заказчик научился генерировать фронтенд через ИИ. Дмитрий Маруськин разобрал галлюцинации, которые ИИ прячет в коде — когда система сравнивает переменную саму с собой под разными именами и говорит «извините» только после того, как ты ткнешь носом.

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

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

Кстати, а как у вас с внедрением ИИ? Уже сокращают коллег или пока только обещают «кратный рост производительности»?

«Серебряной пули не существует» — реальность ИИ в разработке

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

Дмитрий Маруськин, руководитель команды разработки ContentCapture, Контент ИИ, объясняет главное ограничение современных ИИ-инструментов. По его опыту, большинство успешных внедрений требуют человеческого контроля.

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

При этом даже с развитием low-code платформ человеческий контроль остается критически важным. Сергей Ольков, который внедрял ИИ-инструменты в команде разработчиков Диасофт, делится практическим опытом.

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

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

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

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

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

Галлюцинации и контекстные ограничения: почему ИИ все еще нуждается в наставнике

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

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

«Недавно решал задачу на Golang — нужно было применить определенные правила к входным данным и выдать подробный протокол. Составил довольно детальный промпт, ИИ что‑то сгенерировал, и на первый взгляд все выглядело правильно. Но при пристальном изучении кода обнаружились фатальные галлюцинации — настолько глупые ходы, как сравнение переменной самой с собой под разными именами. Когда указываешь на это системе, она отвечает: „Правильно заметили, извините!“ И дело не в качестве промпта — это типичная галлюцинация», — рассказал он.

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

«Серьезныйпрограммный продукт — это не только первоначально написанный код, который запустился и работает. Это тестирование под нагрузкой, которую он должен выдерживать, правильная упаковка и развертывание на целевом стенде, весь DevOps‑процесс. Самое главное — дальнейшая поддержка и внесение изменений в требования. Когда через год‑два приходят новые требования и нужно что‑то поправить в системе, созданной ИИ, это потребует запутанную систему промптов, которая едва ли будет проще обычного исходного кода», — отметил эксперт.

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

«Когда мы переписывали очень большую старую систему, пришлось создать целую инфраструктуру вокруг исходного кода. Специально настроенная модель должна была понимать архитектуру и выполнять правильные действия, но все переписывание происходило только через pull request, которые обязательно проверялись разработчиками. Ограничение контекста — это главный блок для использования LLM, потому что в отличие от человека, языковая модель не может выделить в большом объеме кода действительно значимые участки», — пояснил он.

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

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

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

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

Проблемы с контекстом проявляются и в процессе самого взаимодействия с ИИ. Маруськин обращает внимание на непредсказуемость поведения систем.

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

Low-code платформы как координационный центр микросервисной архитектуры

Если ИИ пока не может самостоятельно создавать сложные системы и нуждается в наставнике, то как организовать работу с ним в масштабе? Особенно когда речь идет о компаниях, где 500 команд разработки работают над единым продуктом. Каждая команда имеет свой релизный цикл, свои технологии, свой график, и каждая может по-разному использовать ИИ-инструменты. Без единой координирующей системы это превращается в хаос — команды начинают изобретать велосипеды, создавать несовместимые API, дублировать функциональность. Современные low-code платформы решают эту проблему, становясь не просто инструментом визуальной разработки, а архитектурным каркасом для микросервисных систем, где ИИ работает в рамках заданных стандартов.

Дмитрий Старов объясняет, как low‑code платформа работает в крупной IT‑компании с сотнями разработчиков.

«В Диасофт работает почти тысяча сотрудников и 200 команд разработки. Чтобы эти команды слаженно работали с микросервисной архитектурой, нужна единая low‑code платформа, которая берет на себя функции, о которых программисту думать не нужно. Аналитик рисует бизнес‑процессы и диаграммы сущностей, а платформа на их основе генерирует скелеты кода, создает CRUD API, сервисы и их описания. После этого программисты добавляют в готовые каркасы необходимую бизнес‑логику, в том числе с использованием ИИ‑инструментов», — рассказал он.

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

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

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

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

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

«Каждая команда, даже состоящая из опытных разработчиков, делает что‑то по‑своему. Когда начинаешь собирать единое приложение из работы разных команд без координирующей платформы, это становится практически невозможным. Чтобы вскопать поле лопатой, кроме лопаты ничего не нужно, но чтобы вскопать поле трактором, нужно пройти обучение работе с трактором и не навредить себе. Low‑code платформа — это трактор, который позволяет делать 43 борозды единого стандарта», — пояснил эксперт.

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

«Мы не требуем от молодых программистов и аналитиков знания всех сложностей микросервисной архитектуры. Платформа обеспечивает связность компонентов. Разработчик садится за этот «трактор», который начинает выполнять стандартизированную работу. Задача программиста — управлять процессом и программировать конкретную бизнес-логику, а платформа берет на себя информационную безопасность, управление ролями, логирование, юнит-тесты, CI/CD pipeline, развертывание, контроль производительности», — подчеркнул он.

Любопытно, но за счет использования low-code можно добиться и определенной независимости при работе с различными ИИ-провайдерами. Алексей Граков объясняет преимущества такого подхода с точки зрения заказчика.

«Мы создаем бизнес-процессы на базе low-code платформ, и каждый элемент процесса может включать обращение к системе искусственного интеллекта. Главное преимущество для бизнеса — гибкость в выборе ИИ-провайдеров. Благодаря модульной архитектуре бизнес-процессов можно легко менять поставщиков ИИ-сервисов. Заменил одного провайдера на другого, а бизнес-процесс остался тем же — никаких доработок в логике не требуется, просто меняется внешний API», — отметил он.

Но есть и ограничения платформенного подхода. Граков честно признает экономические реалии open-source решений.

«Было бы здорово, если бы все low-code платформы были открытыми, но не каждый производитель может себе это позволить. Многие проекты развиваются по модели community + enterprise версий. Чтобы владельцы open source платформ могли зарабатывать, должна быть платная enterprise-версия или кто-то должен их поддерживать финансово. Поэтому много качественного открытого low-code кода в ближайшее время не появится», — пояснил эксперт.

ИИ меняет архитектуру разработки: от кода к оркестрации

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

Дмитрий Демиркылыч, руководитель направления workflow ex‑promt разработки, АО «Нейросети» описывает новую парадигму, которая уже реализована в некоторых исследовательских платформах.

«Google недавно создал research-платформу, где можно генерировать low-code пайплайны при помощи обычного текстового запроса к языковой модели. Принцип простой: мы промптом описываем желаемый пайплайн, система превращает описание в функциональные ноды, а затем эти ноды автоматически связываются в готовый workflow. Но это требует от организаций нового мышления — нужно думать о данных, собирать тестовые датасеты, чтобы понимать, насколько автоматизация действительно работает», — рассказал он.

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

«Сейчас мы переживаем этап реформирования бизнес-процессов. Есть большая задача, которую нужно решить, но для этого ее обязательно нужно декомпозировать на маленькие подзадачи, создать MVP, где одна задача решается качественно, и собрать данные о работе системы. Только потом, основываясь на этих данных, думать, как решить следующую декомпозированную задачу, как добавить новую ветку автоматизации. Через некоторое время большая проблема будет решена комплексно, у системы будет мониторинг, тесты, и это станет действительно production-ready решением», — объяснил эксперт.

Программистов станет больше, но других 

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

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

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

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

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

«Программисты трансформируются — революцию отменить нельзя, значит, нужно ее возглавить. Появляются новые профессии: специалисты по составлению промптов, по подбору правильного контекста, по взаимодействию с ИИ‑системами. Хорошие программисты будут избавлены от рутины, и их производительность должна кратно вырасти при использовании современных low‑code фреймворков и ИИ‑ассистентов. Творческая работа, архитектурные решения останутся за людьми, а рутинное кодирование уйдет к машинам», — отметил он.

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

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

Изменения уже касаются рынка труда. Как упоминалось выше, Алексей Граков из Agizo наблюдает реальные случаи сокращений, но видит и новые возможности.

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

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

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

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

«Год назад мы смеялись над ошибками ИИ в генерации изображений — помните те шестипалые руки? Сейчас люди в соцсетях не могут определить, видео создал ИИ или человек. Та же динамика касается и кода — ошибки, над которыми мы смеемся сегодня, завтра просто исчезнут. Я считаю эти модели невероятно умными сущностями с огромным объемом знаний. Галлюцинации часто происходят от избытка информации, а не от ее недостатка. Процесс направления этого потенциала в нужное русло будет только совершенствоваться», — резюмировал он.

А что думаете вы? Используете ли ИИ в своей разработке? Какие изменения уже заметили в работе своей команды? Поделитесь опытом в комментариях — интересно обсудить, как эти тренды проявляются в разных компаниях и проектах.