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

Большинство людей, сталкиваясь с этим, думают, что ИИ поленился или уперся в лимит токенов. На самом деле всё иначе. Проблема структурная. Инструменты для написания кода на базе ИИ созданы для контроля внутренней согласованности. Они спрашивают: «Совпадает ли всё, что я объявил, само с собой?» Они не спрашивают: «Должен ли такой результат содержать всё необходимое?» Если вы упоминаете две страницы для своего сайта бренда, модель послушно проверяет, ссылаются ли эти две страницы друг на друга. Как только ссылки работают, она считает задачу выполненной. У неё нет врожденного понимания того, что сайту бренда нужны страница «О нас», элементы доверия или способ связи. В её «голове» нет стандарта.

Я называю решение этой проблемы Базовым стандартом полноты (Completeness Baseline).

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

Проверка на трех уровнях

Не все недостающие элементы одинаково очевидны. Полезный стандарт проверяет три различных уровня.

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

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

Наполнение. Есть ли за поверхностью реальные данные или структура? Страница, которая загружается, но содержит лишь текст-заполнитель и не имеет поля для загрузки изображений, — это скелет в костюме. Страница «О нас» без поля для изображения или редактируемого текстового поля не является полной, даже если HTML отрисовывается без ошибок.

Эти три уровня позволяют выявить разные типы пробелов. «Наличие» находит потерянный ботинок. «Доступность» находит ботинок, запертый в шкафу. «Наполнение» находит ботинок без подошвы.

Стандарты по типам

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

Сайты брендов требуют определенных разделов и доступных страниц. Подумайте об «О нас», «Контактах», ссылках на политику конфиденциальности и навигации, которая действительно открывает все основные представления.

API требуют документации, исчерпывающих кодов ошибок и ограничений частоты запросов (rate limits). Рабочий эндпоинт, который возвращает 200 OK при успехе и универсальный 500 при любой другой ошибке, — это не готовый API. Это угроза.

Автоматизации требуют логов и уведомлений об ошибках. Если рабочий процесс ломается в 2 часа ночи, и никто об этом не узнает, пока человек не проверит историю запусков, такая автоматизация не является полной. Наблюдаемость (observability) — это не бонусная функция. Это часть результата.

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

Правила проектирования, которые работают

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

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

Публичный движок, приватные значения. Используйте публичный движок для тяжелой работы, но внедряйте свои приватные данные, конфигурации и соглашения во время выполнения (at runtime). Это сохранит ваши личные или корпоративные методы в безопасности и отдельно от сгенерированного каркаса. ИИ строит каркас. Вы вставляете стекла. Это предотвращает жесткое кодирование (hard-coding) моделью предположений, которые нарушают ваши реальные стандарты или раскрывают конфиденциальные паттерны в публичных контекстах обучения.

Propose, do not auto-advance. Let the AI suggest the next step, but force a human to make the choice. Automate the flow of execution, never the judgment. When a model auto-generates a database migration, an auth scheme, and a payment hook in one breath, you get convenience at the cost of oversight. Make the tool present the plan. Let the developer press the button.

Picking the Right Model for the Job

I tested this across different models and found a clear split in value. Cheaper models handle mechanical bulk shockingly well. They churn out boilerplate, repetitive components, and structural stubs faster than you can type. The expensive models earn their price only when they demonstrate restraint. You want the premium option when it refuses to invent fake fixes and instead flags a genuine gap. A model that hallucinates a workaround for a missing API endpoint is dangerous. A model that stops and says, "This workflow requires a webhook target that is not defined," is worth the cost. Pay for discernment, not volume.

Build Systems, Don't Chase Magic

Do not try to fix AI gaps by throwing bigger models or more prompting tricks at the problem. Fix them with a baseline. The gap is not a capacity problem. It is an expectations problem.

To stop the missing blocks, do three things.

Give the system a completeness baseline before any code is written. Make it a physical checklist that lives next to the task.

Bake your conventions into reusable parts. If you enforce your baseline through templates, lint rules, or pre-built scaffolds, the AI starts from a position of correctness rather than hoping it guesses your standards.

Automate the flow while keeping a human in control of judgment. Let the machines handle repetition. Reserve the decisions for people who understand the context.

Here is one last habit that changed how I work. If you make the same design decision seven times, stop treating it as a one-off choice. That is not repetition. That is a law. Name it. Turn it into a rule. Document it. When you codify the pattern, you remove the chance that an AI will drift away from it the eighth time.

The source for this framework and the original exploration can be found here.

If you want to trade notes with others working through the same problems, you can join the GyaanSetu learning community.