Составление промптов — теперь самый медленный и проблемный способ написания кода с помощью ИИ. Вот быстрый и качественный подход.

Забудьте об изощренных промптах. Перед вами исчерпывающее практическое руководство по повышению продуктивности при написании кода с помощью ИИ — с идеями, которые вы больше нигде не встретите.

«Мифический человеко-месяц» встречает мифического разработчика, работающего с ИИ в 10 раз продуктивнее

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

И знаете, что руководство любит вспоминать в такие моменты? Да, вы, вероятно, уже догадались: мифического разработчика, который работает в десять раз продуктивнее остальных.

Когда прибыль начинает падать, отчаявшийся генеральный директор любит представлять примерно следующее: меньше разработчиков каким-то образом создают в десять раз больше программного обеспечения.

Проблема решена.

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

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

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

Сотни разработчиков, одна кодовая база и целое состояние, потраченное на то, чтобы заставить их код работать вместе.

И это не просто кинематографическое преувеличение. Хотите доказательства? Исследования Microsoft показывают, насколько сильно организационная структура и координация влияют на качество программного обеспечения.

Анимация выше хорошо передаёт суть проблемы. Добавьте разработчиков к независимым задачам — и объём результата может вырасти. Но поставьте их работать над тесно связанным кодом — и затраты на координацию могут поглотить весь ожидаемый прирост продуктивности. Наймите слишком мало людей — и проект будет ползти, пока счета продолжают расти.

Волшебного размера команды не существует. Ошибка здесь может стоить целого состояния.

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

Кому нужно чудо, если у вас есть ИИ и таблица с зарплатами, которые можно сократить?

Не делает ли ИИ весь этот чёртов бардак ещё хуже?

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

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

Посмотрите на анимацию ниже. Вся эта невероятная мощность программирования не значит ровным счётом ничего, если программное обеспечение в итоге не работает. А цифры продуктивности выглядят ещё хуже.

Впечатляющая скорость программирования, правда? Жаль, что само программное обеспечение за ней не поспевает.

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

Не верьте мне на слово. Исследование DORA от Google показывает, что ИИ способен усиливать как сильные, так и слабые стороны уже существующих инженерных практик.

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

Давайте посмотрим на цифры.

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

Верно?

Катастрофа продуктивности при разработке с ИИ: только 2% сообщают о десятикратном росте

К сожалению, данные, похоже, подтверждают наши страшилки о программировании с ИИ. И цифры совсем не радуют: лишь около 2% сообщили о чрезвычайном росте продуктивности благодаря ИИ — в десять раз и более.

Даже эти жалкие 2% основаны на самооценке, а не на независимо измеренном увеличении объёма реально поставленного программного обеспечения.

Заявить о десятикратном росте продуктивности — одно. Выпустить в десять раз больше полезного программного обеспечения, одновременно борясь со скрытыми ошибками, сломанными зависимостями и бесконечной отладкой, — совсем другое.

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

Есть только одна проблема: этого рая нигде нет.

ИИ генерирует горы кода и ускоряет разработку, но превратить весь этот объём в надёжное и коммерчески ценное программное обеспечение по-прежнему остаётся чёртовым инженерным кошмаром.

Можно многократно увеличить скорость написания кода, не увеличив при этом ценность, которую компания реально создаёт.

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

Вот он, парадокс продуктивности ИИ: горы кода, но никакого сопоставимого роста объёма поставленного программного обеспечения.

И даже сам факт выхода программного обеспечения в продакшен ещё не означает, что оно чего-то стоит, потому что остаётся чёртов рынок. Клиентам совершенно безразличны ваш код, созданный ИИ, и красивые показатели продуктивности. Им нужно то, за что они готовы платить.

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

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

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

Так что же, чёрт возьми, идёт не так?

Я подозреваю, что и разочаровывающий рост продуктивности, и коммерчески бесполезное программное обеспечение, созданное ИИ, имеют одну и ту же причину: разработчики неправильно понимают математику и информатику, лежащие в основе эффективной работы с ИИ.

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

Мои пять копеек: выбросьте этого воображаемого программиста из головы, пока он не разрушил ваш код. ИИ не способен надёжно восстановить бизнес-правила или скрытые требования, к которым ему никогда не давали доступа.

Невозможно исправить сломанную спецификацию ещё одним промптом.

Альтернатива? Настоящая инженерия, основанная на математике и информатике, с явными требованиями и независимой проверкой. Именно здесь начинается серьёзный рост продуктивности с ИИ.

Наука, стоящая за этими 2%: перестаньте писать промпты, начните заниматься инженерией

Так как же превратить ИИ из непредсказуемой машины по генерации кода в инструмент, способный выпускать программное обеспечение профессионального качества и действительно давать серьёзный рост продуктивности? Звучит как попытка квадратуры круга, не правда ли? Сейчас вы увидите, почему это не так.

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

Настоящее преимущество начинается тогда, когда вы понимаете, чего ИИ не знает, о чём он способен только догадываться и что вы можете заставить его сделать правильно благодаря нормальной инженерии.

И первая ловушка лежит прямо перед глазами.

Ловушка скрытого контекста: ваш ИИ не знает того, что вы забыли ему сообщить

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

Через несколько секунд вы получите вполне приличный код, правильную обработку ошибок и даже несколько тестов. Всё выглядит отлично, и вам почти не пришлось касаться клавиатуры.

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

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

Более глубокая проблема состоит не просто в нехватке информации. Не хватает семантического контекста: бизнес-правил и зависимостей, которые определяют, действительно ли код является правильным.

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

Эту проблему можно выразить математически.

Реализация, которая нам на самом деле нужна, зависит не только от промпта:

y = F(x, z)

Здесь x — ваш промпт, z — соответствующий контекст: бизнес-правила, инварианты и зависимости, а y — реализация, которая действительно нужна вашему бизнесу.

Дайте двум платёжным системам один и тот же промпт о возврате денег, но пусть одна позволяет несколько частичных возвратов, а другая — только один возврат для каждой транзакции:

F(x, z₁) ≠ F(x, z₂)

Один и тот же промпт, разные контексты, разные правильные реализации.

И если ваш ИИ не имеет доступа к этим правилам, как, чёрт возьми, он должен понять, какая именно реализация вам нужна?

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

Поэтому перестаньте заставлять ИИ угадывать то, что должны явно задавать сами.

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

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

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

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

Брукс предупреждал нас о кошмаре координации ещё в 1975 году. Пятьдесят лет спустя ИИ предлагает способ поставить одного разработчика во главе целой команды программистов — без зарплат всей человеческой команды и без чёртового цирка с координацией.

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

Самая дорогая ошибка при программировании с ИИ: позволить ИИ оценивать ваши бизнес-требования

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

Но вы неправильно поняли собственные бизнес-требования — или вообще забыли о части из них.

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

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

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

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

Вот что вложенные семантические контексты делают с вашими якобы простыми требованиями. Одно правило меняет смысл другого — и удачи вам разобраться в этом чёртовом бардаке с помощью чудо-промпта.

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

Пусть они пишут код. Только убедитесь, что кто-то кроме машины определяет, что на самом деле означает правильное программное обеспечение.

Преобразующий и переносящий ИИ: перестаньте угадывать то, что можно сохранить

К этому моменту я почти слышу ваш вопрос: «Хорошо, я понял. Но как, чёрт возьми, применить всё это на практике в собственных проектах?»

Справедливый вопрос. Вам никто не платит за философские размышления об ИИ, пока сроки проекта летят в огонь.

Ответ заключается в различии, которое я сформулировал в более ранней работе после столкновения с проблемами программирования с ИИ в реальных проектах: преобразующий ИИ против переносящего ИИ.

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

Зачем постоянно заставлять ИИ заново восстанавливать смысл, если мы можем сделать этот смысл явным и переносить его через весь процесс разработки?

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

Один и тот же токен, разный смысл: проблема начинается внутри языка программирования

Возьмём переменную в коде. Её смысл зависит от того, где она находится, к какой привязке относится и какие правила языка на неё распространяются. Один и тот же идентификатор может означать разные вещи внутри замыкания, функции, класса или модуля.

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

Зачем заставлять ИИ угадывать то, что могут точно сообщить детерминированные инструменты?

Это первый принцип переносящего ИИ: переносить уже доступную в системе программирования семантическую информацию вместо того, чтобы снова и снова восстанавливать её из токенов.

Одна и та же переменная, разный смысл в зависимости от того, где она находится в коде. Зачем заставлять ИИ угадывать то, что ваш компилятор уже знает?

Как видно на анимации, одна и та же переменная может означать разные вещи в зависимости от места в коде. Да, ИИ способен разобраться с частью такого контекста, но зачем заставлять его угадывать, если ваши инструменты программирования уже знают правила?

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

Одна и та же концепция, разная геометрия бизнеса

Теперь поднимемся на уровень выше: от семантики языков программирования к бизнес-правилам, которые придают программному обеспечению смысл.

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

Теперь перенесём это в программное обеспечение. Возврат денег в рамках одного договора может означать возврат всей суммы, а в другом — лишь её части.

Одна и та же операция возврата денег, разные бизнес-правила и две совершенно правильные реализации, которые нельзя взаимозаменять.

Видите закономерность? Если нет, ещё раз посмотрите на анимацию.

Одно и то же правонарушение, две правовые системы. В одном случае правила могут совпасть, а в другом — резко противоречить друг другу. Вот что происходит, когда контекст меняет смысл.

Обратите внимание на два контекстных пути в анимации. В зависимости от применяемых правил они могут привести либо к одному и тому же результату, либо к совершенно разным.

Эти две возможности можно выразить математически.

Первый путь — согласование контекстов:

Второй путь — расхождение контекстов:

Здесь I(o,c) — это просто смысл операции o в определённом контексте C. Два контекста могут совпадать в отношении одного правила и расходиться в отношении другого.

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

И именно этим мы займёмся дальше.

Перестаньте прятать бизнес-правила в промптах. Дайте им структуру

Теперь мы подходим к практической части статьи: как, чёрт возьми, справляться со всеми этими вложенными семантическими контекстами, которые продолжают ломать коммерческое программное обеспечение, создаваемое вами с помощью ИИ?

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

Какой же это чёртовски дорогой способ управлять разработкой!

Почему бы не поместить эти правила в полуформальную спецификацию, которую ваши инженерные инструменты действительно способны понимать и проверять?

Посмотрим, как геометрия переносящего ИИ, показанная в наших анимациях, превращается в нечто, с чем разработчик может реально работать.

Начните с сопоставления геометрических понятий с их программными аналогами.

Как YAML представляет геометрию

Таблица показывает соответствия. Теперь применим их на практике.

Вот упрощённая спецификация YAML для нашей операции возврата денег:

Наш пример возврата денег с бизнес-правилами, описанными в YAML: что меняется между договорами, что никогда не должно меняться и в какой момент ИИ обязан перестать угадывать, прежде чем это начнёт стоить вам реальных денег.

YAML — всего лишь удобный способ записывать бизнес-правила. Посмотрите на наш пример возврата: один договор разрешает полный возврат, другой — только пропорциональный, но ни один не допускает повторного выполнения операции. Разные контексты, разное поведение, но часть правил сохраняется в обоих.

Разумеется, запись этих правил в YAML ещё не означает, что программное обеспечение будет им подчиняться. Кто-то должен точно определить, что именно они означают, а механизм контекста должен отклонять отсутствующие или противоречивые требования вместо того, чтобы позволять ИИ угадывать.

И если вы думаете, что строка duplicate_execution: Forbidden в файле сама по себе остановит двойной возврат денег, удачи вам. Вам всё равно понадобятся независимые проверки, способные обнаружить реализацию, нарушающую это правило.

Теперь у нас достаточно деталей, чтобы собрать настоящую инженерную машину.

От семантической геометрии к работающей машине программирования с ИИ

Так как же всё это работает вместе?

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

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

Вот как выглядит вся система:

Вся машина переносящего ИИ: вы определяете бизнес-правила, механизм выясняет, какие из них применимы, ИИ пишет код, а независимые проверки ловят ошибки до того, как генеративный ИИ испортит вашу кодовую базу.

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

А поскольку система отслеживает, какие правила использовались, какой контекст применялся и какие проверки прошли успешно, вы будете знать, что именно нужно пересмотреть при изменении бизнес-требований.

Видите, насколько далеко мы ушли от того простого промпта? Теперь у нас есть бизнес-правила и их геометрические отношения, представленные в YAML и встроенные в систему переносящего ИИ. И да, ваш старый добрый генеративный ИИ по-прежнему занимается программированием, только теперь у него есть нормальная инженерная система, в которой можно работать.

Ещё раз посмотрите на схему выше.

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

Один и тот же возврат денег, два разных договора, два разных правильных ответа. В системе переносящего ИИ правила определяет бизнес-контекст, а не лучшая догадка вашего ИИ-программиста.

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

И за всем этим стоит довольно интересная математика. Предположим, что у каждого контекста C есть собственная семантическая спецификация S_c. Переход между контекстами требует преобразования:

А когда задействовано несколько контекстов, эти преобразования должны подчиняться определённым правилам композиции:

Некоторые правила переживают переход без изменений, другие меняются, а несовместимые контексты могут сделать преобразование вообще невозможным.

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

В чём разница? Теперь за вашим программированием с ИИ стоит наука.

А с переносящим ИИ вы уже на шаг впереди: вы переходите от простого описания контекстного смысла к реальным вычислениям с ним.

Теперь примените это в своём следующем проекте.

Источник