С появлением больших языковых моделей (LLM) парадигма разработки программного обеспечения претерпевает фундаментальные изменения. Однако в ходе практической работы я столкнулся с системным ограничением: существующие платформы AI-ассистентов накладывают жесткие лимиты на объем передаваемого контекста.

Для проекта средней сложности (30–50 файлов, 10–50K строк кода) передача полного контекста за одну сессию часто невозможна без специальных методов компрессии. Ниже я представляю методологию, которую разработал для решения этой проблемы.

🎯 Личный контекст: зачем мне это понадобилось

Я — фулстек-разработчик (бэкенд на Go, есть опыт с Vue.js), и технически мог бы создать портфолио вручную. Но мне было интересно поэкспериментировать: а что, если попробовать управлять проектом через AI-ассистента, но на своих условиях?

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

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

Проблема контекста

Основные платформы имеют следующие ограничения:

Платформа

Лимит файлов

Лимит токенов

Примечание

ChatGPT (GPT-4)

~10-20 файлов

128K

Зависит от интерфейса

Claude 3.5

~20 файлов

200K

Anthropic Console

GitHub Copilot

Окно редактора

~8K

Контекст файла

Cursor

Проект

100K+

Локальная индексация

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

Архитектура метода

Я предлагаю подход, основанный на артефактно-ориентированном управлении контекстом. Ключевая идея — двусторонняя синхронизация между исходным кодом проекта и сжатыми артефактами состояния.

Концептуальная модель

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

Рисунок 1: Поток данных артефактно-ориентированной методологии
Рисунок 1: Поток данных артефактно-ориентированной методологии

Формальное определение артефакта

Для строгого описания метода я ввожу следующее определение:

Определение 1 (Артефакт Контекста). Артефакт контекста A есть кортеж:

A = (M, F, T, G)

где:

  • M — метаданные (заголовок, дата генерации, формат, область действия)

  • F — множество файлов {f₁, f₂, ..., fₙ}

  • T — функция трансформации файла в markdown-блок

  • G — функция группировки файлов по типу (context/assets)

Реализация

Процесс реализован посредством пары скриптов на Python, обеспечивающих генерацию и восстановление состояния.

Скрипты генерации

Рисунок 2: Процесс генерации артефактов
Рисунок 2: Процесс генерации артефактов

Скрипты восстановления

Рисунок 3: Процесс восстановления проекта
Рисунок 3: Процесс восстановления проекта

Разделение режимов работы

Для повышения эффективности я внедрил разделение на два режима работы:

Рисунок 4: Диаграмма состояний режимов работы
Рисунок 4: Диаграмма состояний режимов работы

Экспериментальная оценка

Методология была апробирована на реальном проекте (Jekyll-портфолио, 36 файлов).

Метрики эффективности

Рисунок 5: Сокращение количества файлов в 18 раз
Рисунок 5: Сокращение количества файлов в 18 раз
Рисунок 6: Ускорение в 30 раз
Рисунок 6: Ускорение в 30 раз

Сводная таблица

Метрика

До

После

Улучшение

Файлов для загрузки в AI

36

2

18x меньше

Размер контекста

~500KB

~190KB

2.6x меньше

Время на восстановление

15+ мин

30 сек

30x быстрее

Риск человеческой ош��бки

Высокий

Нулевой

100% воспроизводимость

Аудит изменений

Сложно (36 файлов)

Легко (2 файла)

Централизованный diff

Обсуждение и ограничения

Теоретические следствия

  1. Артефакт как абстракция. Я рассматриваю артефакт контекста как абстракцию проекта, аналогичную байт-коду для исходного кода.

  2. Двусторонняя синхронизация. Паттерн generate → modify → init обеспечивает изоморфизм между проектом и артефактом.

  3. Режимы как типы. Разделение Dev/Editor Mode может быть формализовано как система типов.

Ограничения метода

Важно отметить ограничения применимости данной методологии:

Рисунок 7: Карта ограничений методологии
Рисунок 7: Карта ограничений методологии

Смежные работы

Работа

Год

Фокус

Отличие

LangChain

2023

Цепочки вызовов LLM

Не решает сжатие контекста

LlamaIndex

2023

RAG индексация

Требует векторную базу

GitHub Copilot Workspace

2024

Проектный контекст

Проприетарно

Данная работа

2026

Артефакты контек��та

Открыто, двусторонняя синхронизация

Будущая работа

Я планирую следующие направления развития метода:

Рисунок 8: Дорожная карта развития метода
Рисунок 8: Дорожная карта развития метода

Также предполагается расширение методологии на другие стеки (React/Vue, Python/Django, Kubernetes, Terraform).

Коммерческий потенциал

Методология может лечь в основу следующих продуктов:

Направление

Формат

Целевая аудитория

AI Context Manager

SaaS / self-hosted

Команды, использующие LLM в разработке

Plugin для IDE

Расширение для VS Code / JetBrains

Индивидуальные разработчики

Enterprise-решение

Он-премис инсталляция + поддержка

Крупные компании с требованиями к безопасности

Консалтинг / внедрение

Услуги по адаптации методологии

Команды, переходящие на AI-ассистированную разработку

Заключение

В данной работе я представил Артефактно-Ориентированную Методологию Разработки с AI-Ассистентами. Экспериментальная оценка показала сокращение времени подготовки контекста с 15 минут до 30 секунд при сохранении полной целостности проекта.

Ключевые результаты:

  • Сжатие контекста в 18 раз без потери информации

  • 100% воспроизводимость проекта из артефактов

  • Формальное разделение режимов работы (Dev/Editor)

  • Аудит изменений через версионирование снимков состояния

От автора

Я — фулстек-разработчик, и эта методология родилась не из стремления «войти в тренд AI», а из личного любопытства: можно ли создать проект с нуля через AI-ассистента, но на своих условиях?

Если вы хотите попробовать подход на своём проекте — все скрипты и примеры артефактов доступны в репозитории:

🔗 github.com/nikiforidi/nikiforidi.github.io

Литература

  1. Vaswani, A., et al. (2017). "Attention Is All You Need". NeurIPS 2017.

  2. Chen, M., et al. (2021). "Evaluating Large Language Models Trained on Code". arXiv:2107.03374.

  3. Wilson, A., et al. (2023). "Pair Programming with AI: An Empirical Study". CHI 2023.