Многие используют ИИ как «волшебную кнопку»: написал запрос — получил код. Для веба и бизнес-приложений это работает отлично. Там правят бал шаблоны (CRUD, формы, API). ИИ, обученный на миллионах таких примеров, выдаёт стабильный результат. Но в системном программировании (работа с памятью, драйверы, высоконагруженные ядра) этот подход ломается. Почему? Потому что ИИ — это вероятностная модель («мягкая»). Он предлагает то, что «чаще всего встречается в интернете». А в системном коде «чаще всего» — это часто неоптимально или опасно. Ему не хватает контекста железа и строгих ограничений архитектуры. 🔹 Моё решение: Жёсткая модель знаний Я перестал просить ИИ «придумать». Я начал давать ему «законы». Суть метода — формализация архитектуры перед генерацией кода. Я использую элементы инженерии знаний: Фреймы (Паспорта объектов). Я описываю сущность не кодом, а свойствами. Пример: [ФРЕЙМ: БУФЕР] — Владение: Исключительное. — Выравнивание: 64 байта. — Правило: Копирование запрещено. Продукционные правила (Логика). Жёсткие связи «ЕСЛИ — ТО». Пример: ЕСЛИ «Многопоточная среда» ТО «Обязательна синхронизация». 🔹 Проблема «Соскока» Главная сложность в том, что ИИ постоянно пытается «соскочить» с жёстких рельсов на мягкую колею. Вы задали строгое правило выравнивания памяти, а ИИ в ответ генерирует обычный malloc, потому что «так делают в 90% туториалов». Он нарушает вашу архитектуру, опираясь на статистику, а не на логику. 🔹 Роль инженера В такой связке вы не просто «пишете промпты». Вы — архитектор ограничений. Ваша задача — постоянно возвращать ИИ к модели. «Ты использовал стандартный аллокатор. Это нарушает Фрейм. Переделай через aligned_alloc». 🔹 Итог Этот подход удлиняет цикл разработки на старте (нужно прописать модель). Но он радикально снижает количество архитектурных ошибок. ИИ не заменяет инженера. Но инженер, владеющий инструментами формализации (Фреймы, Семантические сети), получает контроль над генерацией, превращая ИИ из «творца-импровизатора» в надёжного исполнителя.