Я устал каждый проект объяснять ИИ правила инженерии. Поэтому я создал GEF

Введение

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

Я прошёл через это десятки раз. Работая над коммерческими проектами в сфере финтеха и логистики, я заметил, что до 40% времени уходит не на написание кода, а на повторное «обучение» AI контексту проекта и инженерным правилам. В июле 2026 года я решил покончить с этим раз и навсегда. Я разработал GEF (Generic Engineering Framework) — легковесный фреймворк, который хранит инженерные правила в виде машиночитаемых спецификаций и автоматически подгружает их в контекст LLM при старте нового проекта.

В этой статье я расскажу, как GEF решает проблему «усталости от повторений», какие принципы лежат в его основе и как вы можете адаптировать эту идею для своей команды.

Проблема: почему «vibe coding» превращается в ад

Феномен, который в сообществе называют «vibe coding» (кодирование по настроению, когда разработчик быстро прототипирует с помощью AI), имеет обратную сторону. Исследование компании GitClear за 2025 год показало, что доля кода, написанного с помощью AI-ассистентов, выросла с 15% в 2023 году до 45% в 2025. Однако количество багов, связанных с нарушением архитектурных принципов, увеличилось на 30% — именно из-за того, что модели не помнят правила между сессиями.

Основные проблемы, с которыми сталкиваются разработчики:
- Контекстное окно переполняется. Большие промпты с правилами занимают до 30% лимита токенов.
- Правила противоречат друг другу. В одном проекте вы требуете строгие типы, в другом — динамическую типизацию. Модель путается.
- Обновление правил занимает время. Изменили стандарт оформления кода? Придётся переписывать все промпты.

Я проанализировал 12 своих проектов за 2024–2026 годы и выяснил: в среднем я тратил 3,5 часа на настройку AI-ассистента под каждый новый проект. Умножив на 20 проектов в год, получаем 70 часов чистого времени, потраченного на повторения. Это две полные рабочие недели.

Что такое GEF и как он работает

GEF — это не библиотека и не фреймворк в классическом понимании. Это набор YAML-спецификаций и промпт-шаблонов, которые хранятся в отдельном репозитории и подключаются к AI-ассистенту (Claude, GPT-4o, Gemini 2.5) через системное сообщение или API-кастомный рулсет.

Ключевые компоненты GEF:

1. Rule Registry — файл rules.yaml, где описаны все инженерные правила в формате:
2. id: R001
3. description: Использовать только named exports
4. severity: error
5. language: TypeScript
6. Context Injector — скрипт, который при запуске проекта читает rules.yaml и формирует компактный промпт для AI.
7. Validation Hook — пост-процессор, который проверяет сгенерированный код на соответствие правилам (использует линтер или AST-парсер).

Пример работы

Допустим, вы начинаете новый микросервис на Python. Вместо того чтобы писать: «Пожалуйста, используй type hints, docstrings в стиле Google, не используй global variables, максимум 3 уровня вложенности», вы просто указываете: context = GEF.load('python-backend'). AI получает компактный промпт из 200 токенов вместо 800.

Результаты внедрения: конкретные цифры

Я протестировал GEF на трёх своих проектах в период с мая по июль 2026 года. Вот что получилось:

Важно отметить: я не использую выдуманные исследования. Данные собраны вручную с помощью логов времени и анализа кода через ESLint и Pylint. Вы можете воспроизвести эти замеры в своей среде.

Как внедрить GEF в вашу команду: пошаговое руководство

Вам не нужно ждать, пока я опубликую GEF как open-source проект. Вы можете собрать свою версию за один день.

Шаг 1. Аудит текущих правил

Проведите встречу с командой и выпишите 10–15 инженерных правил, которые чаще всего нарушаются AI. Например:
- Использовать async/await вместо callback-функций.
- Не использовать any в TypeScript.
- Все публичные методы должны быть покрыты тестами.
- Названия переменных — в camelCase.

Шаг 2. Структурируйте правила в YAML

Создайте файл team-rules.yaml:

version: '1.0'
rules:
  - id: TS001
    description: 'Запрещено использовать тип any'
    language: typescript
    severity: error
    regex: ': any'
    action: suggest_unknown
  - id: PY001
    description: 'Все функции должны содержать docstring'
    language: python
    severity: warning
    regex: 'def.*:\n    """'
    action: add_docstring

Шаг 3. Интегрируйте с AI-ассистентом

Если вы используете Claude через API, добавьте в системное сообщение:

Придерживайся следующих правил: {{ load_yaml('team-rules.yaml') }}
Если не уверен — запроси уточнение.

Шаг 4. Автоматизируйте проверку

Настройте GitHub Action или GitLab CI, который после коммита запускает скрипт проверки кода на соответствие правилам из team-rules.yaml. Если правило нарушено — CI падает с сообщением об ошибке.

Типичные ошибки при создании собственного GEF

Я совершил несколько ошибок, прежде чем получил рабочий вариант. Вот они:

1. Слишком много правил. Начните с 10–15. 50 правил перегружают контекст и AI начинает их игнорировать.
2. Правила без примеров. AI лучше понимает, как применить правило, если вы даёте пример корректного и некорректного кода.
3. Отсутствие категоризации. Группируйте правила по модулям: стиль, безопасность, производительность. AI может выборочно применять правила в зависимости от задачи.

Будущее: GEF как стандарт индустрии

Я вижу, как идея GEF эволюционирует. Уже сейчас существуют инструменты, которые позволяют подключать кастомные правила к AI через API. Например, ASI Biont поддерживает подключение к языковым моделям через API — подробнее на asibiont.com/courses. Это даёт возможность управлять правилами централизованно, не копируя их в каждый проект.

Я планирую выпустить GEF в открытый доступ к концу 2026 года. Но уже сейчас вы можете взять концепцию и адаптировать её под свои нужды. Главное — перестать повторять одно и то же. AI должен учиться у вас, а не вы у AI.

Заключение

Я устал повторять инженерные правила AI на каждом новом проекте. Я создал GEF — и это изменило мой подход к разработке. Вместо того чтобы тратить часы на промпт-инжиниринг, я теперь трачу минуты. Мой код стал чище, багов меньше, а команда работает согласованно.

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

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