Spec-Driven Development: как построить ГИС-платформу вдвоем за 2,5 месяца с помощью ИИ

Spec-Driven Development: как построить ГИС-платформу вдвоем за 2,5 месяца с помощью ИИ

Создание сложных геоинформационных систем традиционно ассоциируется с большими командами разработчиков, месяцами проектирования и внушительными бюджетами. Однако современные инструменты искусственного интеллекта меняют правила игры. Двое опытных разработчиков поделились успешным кейсом создания коммерческой ГИС-платформы с нуля всего за 2,5 месяца.

Применив подход Spec-Driven Development и используя в качестве основного исполнителя ИИ-агента Claude Code, команда смогла построить систему, способную обрабатывать и агрегировать миллиарды гео-записей. За время проекта было написано около 240 тысяч строк кода, причем разработчики практически не писали код вручную — их фокус сместился на проектирование архитектуры и управление контекстом.

Суть подхода Spec-Driven Development

В традиционной разработке программисты переводят требования аналитиков в код, принимая множество мелких архитектурных решений по ходу дела. В Spec-Driven Development код становится вторичным продуктом, следствием подробных спецификаций. Человек выступает в роли архитектора, описывающего систему, её контракты и логику в текстовых файлах формата Markdown, а ИИ-агент преобразует эти спецификации в работающие программные модули.

Для успешной работы ИИ-агентов кодовая база проекта была организована особым образом:

• Статический контекст: В каталоге docs/product/features/ содержались подробные описания функциональности проекта, а в docs/architecture/ — архитектурные схемы и принципы работы системы.
• Временная шкала решений: Файлы в директориях decisions/, specs/ и plans/ фиксировали текущие задачи, технические компромиссы и пошаговые планы реализации.
• Управление изменениями: Входящие требования и транскрипты обсуждений помещались в каталог inbox/ для автоматической переработки ИИ-агентом в новые спецификации.

Фронтенд и бэкенд приложения были разделены жестким контрактом API, что служило передвигаемой границей для контекста ИИ-агента при генерации кода отдельных частей системы.

Геопространственный стек: PostGIS и Uber H3

Создаваемая ГИС-платформа должна была агрегировать огромные массивы геоданных — около 3 миллиардов GPS-координат перемещений объектов. Для решения этой задачи стандартных возможностей базы данных недостаточно, поэтому команда выбрала стек из PostgreSQL с расшинением PostGIS и системы дискретной глобальной сетки Uber H3.

Uber H3 разбивает всю поверхность Земли на гексагоны различного разрешения. Это позволяет:

• Превратить сложные пространственные запросы пересечения полигонов в простые операции сопоставления гексагонов.
• Быстро агрегировать миллиарды записей на разных уровнях детализации.
• Использовать расширение h3-pg для выполнения быстрых пространственных группировок непосредственно средствами SQL.

Различные разрешения H3 соответствуют конкретным размерам ячеек на местности. Например, разрешение 8 покрывает площадь около 0.7 кв. км (длина ребра 460 метров), что идеально подходит для анализа районов города, тогда как разрешение 10 сужает ячейку до 0.01 кв. км (длина ребра 65 метров) для высокодетализированного отслеживания локальных перекрестков. Шестиугольная сетка имеет преимущество перед квадратной за счет одинакового расстояния от центра до всех шести соседних ячеек, что критически важно при расчетах радиусов зон покрытия и плотности движения.

Итоговая статистика проекта

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

• Объем кода приложения: ~155 000 строк.
• Вспомогательные скрипты анализа геоданных: ~42 000 строк на Python.
• Объем технической документации и спецификаций: ~41 000 строк.
• Динамика работы: 230 объединенных пулл-реквестов, 1928 коммитов.

Пошаговое руководство по внедрению Spec-Driven модели

Если вы планируете использовать ИИ-агентов для генерации сложного приложения, следуйте этой процедуре:

Требования к старту

• Наличие опытного инженера, понимающего системную архитектуру.
• Строгое определение технологического стека и формата обмена данными перед запуском агента.

Шаг 1. Создание структуры документации в репозитории

Создайте папки для статических спецификаций. Инициализируйте конфигурационный файл контекста ИИ, где будут описаны правила форматирования кода, структура проекта и команды сборки и тестирования.

Шаг 2. Фиксация API-контрактов

Перед началом генерации кода бэкенда или фронтенда опишите схемы запросов и ответов. Не позволяйте ИИ менять контракты без согласования.

Шаг 3. Постановка задач для ИИ-агента

Формулируйте задачи в виде сценариев. Ссылайтесь на конкретные файлы требований. Запускайте генерацию кода через интерфейс командной строки ИИ-агента.

Шаг 4. Автоматическая валидация

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

Caveats и ограничения подхода

• Ограничение контекста: У современных ИИ-агентов есть лимит на объем удерживаемой в памяти информации. Без жесткого разделения кодовой базы на независимые модули агент начнет терять нить повествования.
• Поддержание актуальности спецификаций: Если спецификации отстанут от реального кода, ИИ-агент начнет генерировать нерабочий код, опираясь на устаревшие данные.
• Экспертиза человека: ИИ отлично пишет код по четким инструкциям, но не умеет принимать ключевые архитектурные решения.

Данный кейс наглядно показывает, что развитие генеративного ИИ не уничтожает профессию программиста, но существенно смещает фокус его повседневных задач. Инженеры будущего будут тратить меньше времени на написание шаблонного кода и больше — на проектирование надежных систем, формализацию бизнес-требований и контроль качества автоматизированной сборки. Умение правильно структурировать спецификации и управлять контекстом работы нейросетевых агентов становится важнейшим навыком в современной индустрии разработки программного обеспечения.