Мне посчастливилось начать проект с чистого листа: амбициозная задача, никакого легаси и свобода выбрать любой подход. Я решил довериться 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 месяца, и он продолжает расти.
Строки кода:
Часть проекта | Строк |
|---|---|
Документация ( | ~41k |
Код приложения (NestJS API + Next.js) | ~155k |
Инструменты (Python) | ~42k |
Всего | ~240k |
Pull requests и темп:
Метрика | Значение |
|---|---|
Смёрдженных PR | 230 |
Всего коммитов | 1 928 |
Дней с коммитами | 105 |
PR на человека в активный день | ≈ 1,8 (в первый месяц у меня — 2,2) |
Добавлено строк на один PR | ≈ 1 930 — по истории коммитов, включая переписанные позже |
Заключение
Итоги
У нас не было опыта работы с геоданными — и всё же мы построили систему, в которой геоданные несут всю основную нагрузку.
Проект живёт уже 4,5 месяца и растёт: новые фичи выкатываем каждый день — без роста стоимости разработки и просадки качества.
Страх из начала статьи не сбылся: в лимиты контекста мы так и не упёрлись, а скорость к концу проекта не просела.
Результатом я доволен: это лучшее сочетание качества кода, тестов и документации за мои 25 лет в разработке. Причём 20 из них я писал backend на Java, а на TypeScript перешёл только полтора года назад.
Ядро делали вдвоём с кофаундером: он — Product Owner и frontend, я — архитектура и backend. Позже подключился третий человек — по данным.
Самый болезненный инсайт
Код больше не надо трогать руками.
Написание кода превратилось в интеллектуальное развлечение — вроде игры в шахматы. Приятно, но прямой пользы бизнесу не несёт. Ценность сместилась в управление продуктом и организацию контекста. Код — уже следствие, как деталь, сходящая с правильно настроенного ЧПУ-станка.
Но это не значит, что инженер больше не нужен. Наоборот, именно инженерное мышление отделяет рабочую систему от красивой галлюцинации. Просто мыслить теперь нужно на уровне архитектуры, а не кода.
Что дальше
Продукт ответил на вопрос бизнеса: сказал, где строить, — и клиент пошёл строить. А мы ищем, что делать с этим опытом дальше. Для нас он сложился в три вектора:
Система. Скоринг не привязан к магазинам — его легко адаптировать под любую нишу, где нужно оценивать и ранжировать локации.
Команда и процесс. Мы научились быстро проходить путь от идеи до боевой системы — и собрали команду, которая умеет это повторять.
Подход. Ту же организацию контекста я использую уже в десятке пет-проектов — например, qrshare.io и t-ntfy (бот, код). А на основном рабочем проекте сейчас натягиваю «семантический слой» на legacy-систему — чтобы получить ту же скорость разработки в существующем коде.
Ваш опыт
Вы ещё заглядываете в код — или уже доверяете агенту и работаете с кодом как с «чёрным ящиком»?
Как вы организуете контекст в проекте — и как им делятся участники команды?
Как поменялся ваш подход к разработке за последние пару лет?
На правах рекламы: я веду телеграм-канал «ИИ без воды» — делюсь приёмами использования ИИ на практике, для разработки и личной продуктивности. Связаться с нами: Сергей Ройз · Сергей Воронов.
