Разработка программного обеспечения есть сложный процесс взаимодействия множества сущностей: специалистов в разных областях (от непосредственно написания кода до управления), средств разработки (от языков программирования и IDE до багтрекеров и систем хранения знаний) и артефактов (таски, логи, отчёты, планы и тп). Отношения этих сущностей описываются, объясняются и регулируются парадигмами различной степени абстрактности. Одни, например, носят сугубо прикладной характер. Другие созданы искусственно ради красивого акронима, что, впрочем, не отменяет их практической ценности. Третьи таковы, что о самом факте их использования мы начинаем догадываться только ближе к начислению годовой премии.

Но прогресс вносит свои коррективы, и в разработке ПО появляется новая сущность — так называемый «искусственный интеллект». Что же это такое? Это точно не язык программирования и не фреймворк, но это уже и не инструмент (в привычном нам понимании). В то же время, это ещё далеко не полноценный коллега. Поэтому возникает потребность в осмыслении роли этой новой сущности, способов и целей её использования.

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

1. Промпт — первым приоритетом! Значимость промпта; промпт как основа любой работы с ИИ

2. Разбор результата и рефлексия. Необходимость обратной связи между ИИ и "внешним миром"

3. Однозначность и определённость. Детерминированность ответа ИИ входными параметрами

4. Самостоятельность сотрудника. Изменение роли человека с появлением ИИ; восприятие и позиционирование ИИ

5. Творчество и тактика. Выбор и постановка задач для ИИ

6. Амбициозность апгрейда. Технический прогресс как фактор планирования

Рассмотрим каждый из этих принципов подробнее.

Примечание 1. В этой статье под ИИ я подразумеваю, в первую очередь, различные генеративные модели, построенные на их основе агенты и сопутствующее ПО, но, впрочем, не исключаю и другие значения.

Примечание 2. Под термином «мясной» я понимаю людей, сотрудников и программистов, к которым в полной мере применимо определение жизни как формы существования белковых тел. Если вам такое определение кажется обидным, то вспомните о том, что ИИ уже проходит тест Тьюринга. Работая удалённо, мы в ряде случаем уже сейчас рискуем не отличить живого человека от модели.

П: Промпт — первым приоритетом!

Промпт есть новый исходный код, и даже больше.

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

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

Требуется обновить картинки в проекте? Как жаль что дизайнер занят. Или он потерял PSD c исходниками (ведь дизайнеры не умеют пользоваться системами контроля версий)? Пусть промпт к text-to-image модели станет исходником картинки. Тогда перекрасить или чуть-чуть изменить картинку можно будет редактированием текстового файла.

Принцип «Промпт — первым приоритетом!» говорит о значимости роли промпта в любом процессе, для которого применим ИИ.

Р: Разбор результата и рефлексия

ИИ должен иметь доступ к результатам своей деятельности.

Давайте проведём небольшой эксперимент. Откройте самый простой текстовый редактор, какой у вас есть, и попробуйте написать что-то более-менее комплексное на своём любимом языке программирования. Например, напишите разворот двусвязного списка. Сложновато, правда? Не хватает автокомплита, лога компиляции, подсветки синтаксиса и всего того, к чему мы привыкли в IDE. Наверняка вы, даже если не допустите концептуальных ошибок, забудете какую-нибудь синтаксическую мелочь или правильное название метода. Что уж говорить о реализации функциональности, размазанной по десяткам файлов! Вряд ли кому-то под силу написать её без ошибок с первого раза.

Так почему же мы требуем от ИИ сразу выдавать работающий код? «Смотрите, какой глупый этот ваш чатбот! Вместо substring он написал substr! Такое даже не компилируется!» А что, если чатбот сам запустит javac и посмотрит результат его работы? Сумеет ли он тогда найти ошибку?

Пусть ИИ получит доступ ко всей той информации, к которой имеет доступ «мясной» программист: логам компиляции, вориннгам линтеров, автокомплиту, навигации по коду и прочим «человеческим» инструментам (обобщённо всё это можно знавать «внешним миром»). Столкнувшись с ошибкой, пусть он пытается её исправить. Пусть он пишет тесты и добивается их выполнения. Пусть запускает написанные приложения и открывает свёрстанные странички в браузере. Словом, работает так же, как работает «мясной» программист.

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

О: Однозначность и определённость

Ответ ИИ должен однозначно определяться промптом и только им.

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

Если вдруг кому-то становится неловко от термина «промпт», то в него можно включить не только собственно текст, но и название модели, её ревизию, зерно генерации и другие необходимые параметры. Мы говорим «промпт», а подразумеваем «всё множество параметров».

В то же время, если что-то изменится во «внешнем мире», например из SDK будет удалён устаревший метод, и это изменило лог компиляции, модель должна прореагировать на это. Сигналы из «внешнего мира», согласно принципу «Разбор результатов и рефлексия», это тоже часть параметров.

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

С: Самостоятельность сотрудника

Следует считать ИИ достаточно самостоятельными для решения поставленной задачи (по крайней мере до тех пор, пока не будет очевидно обратное).

Многие начинающие руководители попадают в ловушку страха делегирования. «Я сделаю лучше», «Я сделаю быстрее», «Долго объяснять», — говорят они. В итоге «руководитель» вместо своих задач решает задачи своих подчинённых. Способна ли такая система к масштабированию, при условии что в сутках всё ещё 24 часа, а у начинающего руководителя всё ещё только две руки?

С большой вероятностью начинающий сотрудник будет решать задачу дольше, задаст кучу вопросов и в итоге всё равно сделает что-то не так. Но если работать над постановкой задач и давать обратную связь, то через определённое время сотрудник научится работать так, как от него это ожидается, и эффективность очевидным образом увеличится. Добавьте ещё подчинённых, и производительность ещё вырастет (хотя, конечно, зависимость между количеством программистов и скоростью разработки хуже линейной, что заслуживает отдельного исследования).

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

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

Принцип «Самостоятельность сотрудника» описывает то, как «мясному» сотруднику следует воспринимать ИИ: больше, чем просто инструмент, скорее как подчинённого или целый отдел в своём подчинении.

Т: Творчество и тактика

Работайте с ИИ так, словно он способен творить, оценивать ситуацию и принимать тактические решения.

Способен ли ИИ творить на самом деле — вопрос холливарный даже в части определения термина «творчества». Лично я уверен, что ни «мыслить», ни «творить» модели не способны. Они лишь изображают этот процесс с некоторой степенью подобия. Даже не изображают, а только оперируют векторами и матрицами огромной размерности. Категорией «мыслит или не мыслит» эти вектора наделяется нашим «мясным» разум. Но для решения прикладных задач такого поведения может быть вполне достаточно. Как говорил Владимир Ханин, «Творцы нам тут не нужны».

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

Инструменту мы даём максимально формализованную задачу. Делая выборку из БД, мы явно указываем что, откуда и как мы выбираем:

SELECT
	last_name, first_name
FROM
	doctors
WHERE
		last_name LIKE ‘Копытин’
	OR
		last_name LIKE ‘Тройкин’

Работая с человеком, мы можем (и должны, иначе зачем нам люди!) ставить более общие задачи: «Пошли депешу знахарю с лошадиной фамилией». Человек, если он достаточно мотивирован, начнёт перебирать возможные фамилии и делать запрос по каждой из них.

Так же мы поставим задачу ИИ:

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

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

Принцип «Творчество и тактика» призывает ставить ИИ более абстрактные, допускающие некоторую свободу принятия решений, задачи.

А: Амбициозность апгрейда

Возможности ИИ растут экспоненциально

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

Вчера DeepDream генерировала спагетти с пёсьими головами. Сегодня Veo 3 снимает вполне правдоподобные ролики про домашних животных. Завтра, скорее всего, мы будем в пару кликов создавать уникальные фильмы на вечер (если быстрее не переселимся в капсулы с LCL).

Производительность и качество моделей растёт экспоненциально, как растёт и производительность железа. Если в текущий момент использовать ИИ вам кажется нерациональным (слишком дорого, слишком долго, недостаточное качество и тд и тп), то это не повод отказываться от его использования в перспективе. Уже сейчас стоит начать создавать инструменты, писать интеграции и собирать метрики (разумеется, с использованием изложенных выше принципов!), чтобы всё было готово к моменту появления подходящих моделей и подходящего железа.

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

Заключение

Практическое использование ИИ это уже не вопрос «стоит ли?» Это вопрос «как?» Мы, «мясные» айти-специалисты, должны быть готовы к переменам, которые уже начинаются. Часть этой подготовки это создание концепций, парадигм и принципов новой работы. В этой статье я постарался внести свой вклад, предложив концепцию ПРОСТА. Надеюсь, это поможет ПРОСТА использовать ИИ уже сейчас!

ЗЫ Да, акроним ПРОСТА придуман ИИ. Нет, принципы, входящие в концепцию, я вывел из личного опыта и опыта моих коллег (тех, которые «мясные»).

ЗЗЫ В этой статье я 44 раза написал «ИИ». Ой, уже 45.