Как работать с ИИ-генерацией кода: уроки CASE-инструментов 90-х

Спецификация как источник правды, генерация вместо ручного набора кода, ревью до сборки — всё это обсуждают так, будто придумали вместе с языковыми моделями. На деле те же принципы лет тридцать назад держались на Oracle CASE, S-Designer и PowerBuilder. Поменялись инструменты, философия осталась.

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

Что CASE-инструменты делали иначе

Oracle CASE генерировал формы и PL/SQL, но ценность была не в генераторе. Ценность была в репозитории: таблицы, экраны, связи описывались в одном месте, и всё остальное выводилось из этого описания. Качество шло из управления моделью. Разработчик занимался намерением и структурой, а не повторяющейся механикой реализации.

Инструменты были тяжёлыми, проприетарными и жёсткими. Философия при этом оказалась верной.

S-Designer, позже известный как PowerDesigner, довёл идею до рабочего ритуала: требования поменялись — идёшь в модель, правишь, регенерируешь. Никто не поддерживал код — поддерживали проект. Что оставалось после смены требований, так это проектный артефакт, а не конкретная реализация.

PowerBuilder сделал то же самое в практичной форме: декларативный интерфейс, привязанный к схеме базы, автоматический SQL и CRUD, быстрая пересборка работающего приложения. Первый low-code задолго до того, как появился сам термин.

ASP.NET Maker добавил жёсткое правило, которое тогда считали скорее ограничением: сгенерированный код нельзя редактировать. Тронул вывод — сломал контракт. Нужно другое поведение — меняй схему или конфигурацию и генерируй заново. Неудобно и полезно одновременно.

Почему от центрального репозитория отказались

В двухтысячных от центральной модели ушли сознательно. Тяжёлые рабочие места, синхронизация репозитория, установка клиента — всё это мешало скорости. VS Code, командная строка, IntelliSense, рефакторинг в CodeRush, шаблоны MVC-скаффолдинга из схемы базы: склонировал репозиторий — и через пару минут уже пишешь код. Цикл обратной связи сжался с минут до миллисекунд.

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

Три эпохи

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

Что переносится в работу с ИИ

Библиотека промптов и спецификаций — ваш новый репозиторий

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

Не правьте сгенерированное руками

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

Поставьте критика в процесс

Старые инструменты работали как стена: схема не совпала с моделью — ошибка, дальше нельзя. Модель так не умеет, она согласится почти со всем. Отсюда привычка проверять не только результат, но и постановку. В DevSpark для этого есть отдельный шаг — critic prompt, который перед сборкой задаёт неудобные вопросы:

Вы это продумали до конца? Что произойдёт на масштабе? Это решает реальную проблему или только видимую?

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

Документируйте модель, а не только код

Через полгода вам понадобится не описание того, что написано в файлах, — это и так видно. Понадобится «почему»: какие ограничения учитывали, какие варианты отбросили и на каком основании. Эти записи переживут и рефакторинг, и смену модели.

Где подход не работает

Не каждый проект заслуживает спецификации. Одноразовый скрипт, разведка незнакомого API, прототип на два дня — здесь описание дороже результата, и правки в выводе генератора нормальны: выкинуть всё равно придётся.

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

Что в итоге

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

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