Разработчикам программного обеспечения придется получать удовольствие от роли наставников ИИ, профессоров по инженерии запросов и мастеров своего дела.
Так считает Пратик Вадхер, технический директор Kaseya, который руководил командой разработчиков, переписывавших программное обеспечение в портфеле управляемых услуг компании, охватывающем удаленный мониторинг и управление, резервное копирование и восстановление, кибербезопасность и автоматизацию.
«Цель состоит в унификации наших данных, унификации нашего API, но поскольку мы начинаем также рассматривать наш портфель продуктов, мы пытаемся понять, какие шаблоны мы можем использовать для консолидации рабочих процессов продуктов», — говорит он The Register.
Хранение данных — хороший пример. Основные рабочие процессы включают чтение и запись данных в массивы хранения, собственную облачную среду Kaseya или стойки, управляемые гиперскейлерами. Команда переработала бэкэнд своих продуктов хранения данных, чтобы движок хранения читал и записывал данные в любой тип хранилища, от ZFS до S3.
«Вот где помогает ИИ, — утверждает Вадхер. — По сути, мы ускорили эту часть перепроектирования».
С момента прихода в Kaseya в сентябре 2025 года технический директор пытается упростить то, что, по его признанию, может быть «запутанным» количеством отдельных продуктов.
«Слой хранения данных, который мы писали, мы переработали и написали за шесть недель. И это фактическое написание, внедрение и тестирование кода. За этим стоят годы экспертных знаний в предметной области, чтобы понять, как мы хотим его написать».
В процессе Kaseya использовала кодовых агентов Anthropic, чтобы помочь человеку написать спецификацию. Затем «мясные мешки» в Kaseya доработали ее и провели рецензирование с помощью агентов для критики, после чего ИИ сгенерировал код. Claude от Anthropic становится «де-факто стандартом» для написания кода в Kaseya.
«Когда я смотрю на своих инженеров, это не то, как я раньше писал код. Это почти как я манипулирую этими агентами, но лучшие инженеры по-прежнему критичны, потому что вы накопили большой опыт в понимании того, что вам нужно делать», — говорит Вадхер.
Не отнимает ли это удовольствие от программирования? Да и нет, утверждает он. Отражая тенденции в отрасли, некоторые инженеры Kaseya принимают новый подход, а некоторые более «нерешительны».
«Удовольствие от программирования будет заключаться в дизайне, архитектуре, мышлении. Написание кода — это весело, но я не думаю, что это [главная] веселая [часть]. Веселье — это когда код работает, когда видишь, что он может делать, а затем дорабатываешь и меняешь его. Если вы можете ускорить это и начать видеть результаты, я думаю, по крайней мере для меня, это будет самое интересное: видеть эффект».
«Разработчики должны стать опытными составителями запросов, и вам нужны экспертные знания в предметной области, — добавляет он. — Если вы просто используете ИИ для генерации кода, я не думаю, что вы будете полезны, и я не думаю, что код, который вы пишете, будет полезен».
Некоторые читатели Reg и некоторые «стервятники», пишущие статьи, могут не согласиться. В мире FOSS, например, происходит явный раскол, где некоторые проекты хотят только код, написанный человеком, а другие придерживаются того, что они называют более прагматичным взглядом на инструменты ИИ.
ИИ уже вынуждает технологический сектор к изменениям. Исследование прошлого года показало, что число выпускников, начинающих карьеру в сфере технологий, резко падает, поскольку определенные функции поглощаются агентами.
«Я думаю, что базовые задачи будут выполняться ИИ, так что они вам не понадобятся, — говорит Вадхер. — Навыки, которые будут чрезвычайно важны, — это критическое мышление и письмо.
«Самая неприятная часть программирования, [то, что] инженеры ненавидят, — это написание документации. Ну, угадайте что? Это станет еще более важным сейчас. Умение писать четкие, лаконичные проектные спецификации, функциональные спецификации будет чрезвычайно важно. Хорошая новость в том, что теперь у вас будет [ИИ] партнер, который сможет делать это вместе с вами, и вы сможете итерировать с этим партнером.
«Я бы сказал, что новый код — это спецификация. Вот что вы будете отправлять в GitHub сейчас, потому что вы хотите убедиться, что спецификация, которую вы написали, будет генерировать один и тот же тип кода снова и снова. Я видел вариации». ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Paul Kunert
