Мне посчастливилось начать проект с чистого листа: амбициозная задача, никакого легаси и свобода выбрать любой подход. Я решил довериться AI по-максимуму и код больше не трогал.

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

Задача

В одной стране, где, по легенде, стоит резиденция Дракулы, идёт бурный экономический рост — и торговые сети наперегонки строят магазины. Рынок ещё не насыщен: у Lidl в Германии 39 магазинов на миллион жителей, в Чехии — 29, здесь — около 20. Конкуренты открывают по 15–25 точек в год. Кто первым займёт хорошие участки — тот и заберёт рынок.

Выбор участка под магазин — это самый долгий и рискованный этап экспансии. Масштаб задачи: среди ~13 млн кадастровых участков найти места для ~600 будущих магазинов. Раньше выбирали вручную: менеджеры действовали по интуиции — так открывали 5 магазинов в год. План клиента — выйти на 20.

Интуицию заменили математикой. Как клиент выбирает участки, мы не знали — приняли это за «чёрный ящик». Зато знали результат выбора: действующие магазины. В терминах ML это Positive-Unlabeled постановка: есть положительные примеры, а размеченных отрицательных нет — обучать классическую модель не на чем. Поэтому начали с простого: придумали признаки, эмпирически расставили им веса и посчитали взвешенный балл для каждого магазина сети — получился ранкинг. Считаем тот же балл для свободного участка — и видим, какое место он занял бы среди действующих магазинов. Так мы выразили свободные участки в существующих магазинах.

Что мы построили

Мы построили систему, которая сводит воедино полтора десятка источников данных: государственный реестр населённых пунктов, перепись, дорожный граф OpenStreetMap, кадастр, GPS-трафик, объявления о продаже земли, координаты магазинов двух десятков торговых сетей. К удивлению, такую базовую вещь, как координаты всех населённых пунктов страны, не знает даже Google Maps — их пришлось сводить из Mapbox, GeoNames и государственного реестра. По каждому городу собрали население, гендерный баланс, покупательную способность, класс дорог — от шоссе до просёлка — и транспортную доступность: сколько людей доберётся до точки за 15 и 30 минут.

Самым ценным источником оказался GPS-трафик. Бесплатные мобильные приложения записывают геопозицию, агрегаторы скупают её — и эти данные можно достать. За год по всей стране — около 3 млрд записей.

Скоринг работает на двух уровнях: города — куда вообще имеет смысл смотреть — и участки внутри перспективных городов. Параллельно система парсит местные маркетплейсы земли и следит за новыми объявлениями. На выходе менеджер получает приоритетный город и участок — остаётся найти владельца земли.

Для этой работы построили CRM: комментарии, документы, ответственные, статусы, уведомления. Всё, чтобы вести участок от «модель подсветила» до «клиент подтвердил: строим здесь».

Подход — spec-driven development

Теперь — как мы это построили. Главное здесь — организация контекста для агентской разработки.

В первый день мы рисовали архитектуру вручную: доменную модель, роли, связи между компонентами. А потом я записал 40-минутный созвон и отдал транскрипт LLM — этого оказалось достаточно, чтобы она сгенерировала PRD и диаграммы лучше, чем мы нарисовали за полдня.

Код — следствие документации

В проекте две сущности: документация и код. Код — следствие набора спецификаций. Документация живёт на двух осях:

• статическая ось — срез системы: актуальная архитектура, компоненты, фичи. Обновляется после каждой выкаченной фичи;

• временна́я ось — лог событий: спецификации, планы, архитектурные решения — что и почему мы решили (в терминах Event Sourcing).

Эта модель отражена прямо в структуре репозитория — вот её ядро:

.
├── .claude/
│   ├── skills/         ← переиспользуемые скиллы
│   └── commands/       ← слэш-команды
│
├── docs/
│   ├── product/        ── срез: что продукт есть сейчас
│   │   ├── features/   ← одна фича = один файл
│   │   ├── architecture/ ← снимок системы; обновляется после каждой фичи
│   │   └── PRD.md      ← задача, пользователи, требования
│   │
│   └── process/        ── лог событий: как мы к этому пришли
│       ├── decisions/  ← ADR — архитектурные решения, append-only
│       ├── specs/      ← что делаем (рождаются из brainstorming)
│       └── plans/      ← как делаем, по шагам
│
├── ops/                ── эксплуатация: скрипты, деплой, рутины
└── src/                ── код — следствие всего, что выше

Начать с такой структуры можно с моего seed-репозитория: agentic-repo-seed.

Агент видит и историю решений, и текущую архитектуру. Он вычленяет архитектурные паттерны проекта и расширяет систему, следуя им.

Как менялся процесс

Начинали до того, как у Anthropic появились Superpowers, поэтому роли написали сами: критик и исполнитель. Я описывал фичу, агент генерировал план, критик проверял его на расширяемость, безопасность и соответствие требованиям. Я вычитывал план, пока вопросов не оставалось ни у меня, ни у критика, — и только после этого начиналась имплементация.

С переходом на Superpowers процесс почти автоматизировался: брейнсторминг, спецификация, утверждение, план, реализация. План я уже не читаю, код почти не смотрю — руками тестирую только edge-кейсы.

Отдельно — про сбор входящих. В проекте есть Inbox, куда падают транскрипты всех встреч; из них мы выделяем фичи и архитектурные решения. Первые две недели работали в режиме хакатона, потом завели трекер задач. В нашей модели у трекера скромная роль: это хранилище одноразового — обсуждений и комментариев, которые не описывают состояние системы и которые не жалко выкинуть.

Главное наблюдение: чем больше контекста накапливалось, тем быстрее шла разработка. В какой-то момент стало достаточно сказать «добавь в CRM такую-то сущность» — и агент по накопленным примерам сам создавал таблицу, сервис, контроллеры и фронтенд, и всё это вписывалось в дизайн продукта.

Стек

• Backend: TypeScript + NestJS (API). Backend и frontend намеренно разделены.

• Frontend: Next.js (React) с server-side рендерингом.

• База: PostgreSQL. Для кадастра и GPS сначала использовали BigQuery, но предвычисленные индексные слои для быстрого рендера на карте всё же занесли в Postgres + расширение PostGIS.

• Карта почти в реальном времени: использовали H3 — гексагональный геоиндекс Uber. Для каждого уровня зума предвычислили гексагональные тайлы, и при отрисовке карта подгружает сотни объектов вместо миллионов — при 3 млрд исходных GPS-записей.

• Агентная разработка: Claude Code + Superpowers skills.

Отдельно про разделение backend/frontend. С одной стороны — бутылочное горлышко. С другой — точка формализации контракта между слоями. Для агентов это дополнительный harness: строгая граница удерживает архитектуру и качество кода.

Статистика

Вот из-за чего я сам себе не верил. Все цифры — из git-истории проекта (2026-02-16 → 2026-06-30). Ядро собрали за ~2,5 месяца; сейчас проекту ~4,5 месяца, и он продолжает расти.

Строки кода:

Pull requests и темп:

Заключение

Итоги

• У нас не было опыта работы с геоданными — и всё же мы построили систему, в которой геоданные несут всю основную нагрузку.

• Проект живёт уже 4,5 месяца и растёт: новые фичи выкатываем каждый день — без роста стоимости разработки и просадки качества.

• Страх из начала статьи не сбылся: в лимиты контекста мы так и не упёрлись, а скорость к концу проекта не просела.

• Результатом я доволен: это лучшее сочетание качества кода, тестов и документации за мои 25 лет в разработке. Причём 20 из них я писал backend на Java, а на TypeScript перешёл только полтора года назад.

• Ядро делали вдвоём с кофаундером: он — Product Owner и frontend, я — архитектура и backend. Позже подключился третий человек — по данным.

Самый болезненный инсайт

Код больше не надо трогать руками.

Написание кода превратилось в интеллектуальное развлечение — вроде игры в шахматы. Приятно, но прямой пользы бизнесу не несёт. Ценность сместилась в управление продуктом и организацию контекста. Код — уже следствие, как деталь, сходящая с правильно настроенного ЧПУ-станка.

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

Что дальше

Продукт ответил на вопрос бизнеса: сказал, где строить, — и клиент пошёл строить. А мы ищем, что делать с этим опытом дальше. Для нас он сложился в три вектора:

• Система. Скоринг не привязан к магазинам — его легко адаптировать под любую нишу, где нужно оценивать и ранжировать локации.

• Команда и процесс. Мы научились быстро проходить путь от идеи до боевой системы — и собрали команду, которая умеет это повторять.

• Подход. Ту же организацию контекста я использую уже в десятке пет-проектов — например, qrshare.io и t-ntfy (бот, код). А на основном рабочем проекте сейчас натягиваю «семантический слой» на legacy-систему — чтобы получить ту же скорость разработки в существующем коде.

Ваш опыт

• Вы ещё заглядываете в код — или уже доверяете агенту и работаете с кодом как с «чёрным ящиком»?

• Как вы организуете контекст в проекте — и как им делятся участники команды?

• Как поменялся ваш подход к разработке за последние пару лет?

На правах рекламы: я веду телеграм-канал «ИИ без воды» — делюсь приёмами использования ИИ на практике, для разработки и личной продуктивности. Связаться с нами: Сергей Ройз · Сергей Воронов.