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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A = (M, F, T, G)

где:

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

В данной работе я представил Артефактно-Ориентированную Методологию Разработки с 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.