Привет, Хабр.

Я 16 лет работал с MS SQL Server, и профайлер был там одним из главных рабочих инструментов при расследовании проблем производительности. Сейчас я в «Тантор Лабс», мы развиваем СУБД Tantor Postgres. И вот когда понадобился аналогичный инструмент для PostgreSQL, то оказалось, что его просто нет. В статье я хочу показать процесс создания работающего профайлера для PostgreSQL на основании моего опыта работы с MS SQL.

При работе с информационными базами на MS SQL Server профайлер часто приходилось использовать для того, чтобы найти дедлоки или «выловить» план проблемного запроса для расследования проблем производительности приложения. Можно было использовать как Extended Events внутри Management Studio, так и отдельное приложение Profiler.

После перехода на PostgreSQL оказалось, что таких инструментов нет, а потребность в них у разработчиков и DBA осталась. В качестве первого шага наша команда разработки реализовала для СУБД Tantor Postgres расширение pg_trace. Реализация этого расширения дала для сбора трассировки программный интерфейс, оставалось реализовать визуальный. Его мы планируем реализовать в платформе Tantor — это инструмент для графического управления и администрирования кластерами PostgreSQL, и вполне логично инструмент для работы с трассировкой реализовать там. Но если ранее я ставил задачу на реализацию подобного инструмента в Jira, и ждал, пока команда дизайнеров отрисует макет в Figma, согласует его с разработкой и представит заинтересованным лицам на согласование, то теперь я могу сделать это сам с помощью ИИ. Это меняет подход к процессу разработки фич: команде дизайнеров и разработчиков можно наглядно показать, как должен выглядеть инструмент, как работает его механика, какие‑то нюансы и тонкости, которые я знаю заведомо глубже просто в силу опыта работы с подобными инструментами. Этот опыт благодаря ИИ я могу представить команде в виде работающего MVP.

Эта статья будет полезна прежде всего тем, кто хорошо знает предметную область, но не является разработчиком — product owner‑ам, аналитикам, DBA, архитекторам. Я покажу на конкретном примере, как с помощью ИИ можно самому пройти путь от идеи до работающего MVP, не написав при этом ни строчки кода вручную.

Содержание статьи:

  1. Проектирование дизайна

  2. Разработка приложения

  3. Отладка приложения

  4. Демонстрация работы профайлера

План действий был таким:

  • спроектировать внешний вид профайлера в Claude Design;

  • экспортировать его в Claude Code, реализовать приложение;

  • далее отлаживать на тестовом сервере с установленным Tantor Postgres + pg_trace.

Начнем.

Проектирование дизайна

Мой промпт для проектирования интерфейса в Claude Design выглядел так:

Скрытый текст

Задача: спроектировать интерфейс профайлера (Profiler) для визуального сбора трассировок запросов PostgreSQL по аналогии как реализовано в MS SQL Management Studio.

Входные данные для проектирования интерфейса:
1. Перед стартом трассировки необходимо определить ее параметры:
Base — выбор базы из списка
backend_pid — числовое поле
duration — числовое поле
query_like — текстовое поле
plan — булево
timeout — числовое поле
Все эти поля располагаются на уровне одной строки
2. Под параметрами сбора трассировки расположить список кнопок для управления трассировкой: старт, стоп, Clear Data, Filters, Clear all Filters, Grouping, Aggregation.
Кнопки отобразить предпочтительно иконками и текстом при необходимости.
3. Под командной панелью располагается 2 окна: сверху таблица со строками, снизу расшифровка каждой строки. Список полей верхней таблицы и ее расшифровки я определю на этапе кодинга, сейчас просто в дизайне отображаем наличие этих 2 окон.
4. Нижнее окно состоит из двух вкладок — Details, которая отображает все колонки анализируемой строки, и Query Plan, которая будет отображать план запроса через iframe

Прикладываю следующие референсы:
mssql_command_panel — команды управления трассировкой в MS SQL Management Studio, то что упомянуто в пункте 2 выше.
mssql_window — как выглядит целиком окно сбора трассировки в MS SQL Management Studio. Поля из п.1 здесь задаются по другому, но мы в целях упрощения интерфейса сделаем все в одном окне.
mssql_plan — как выглядит отображение плана запроса. Пункт 4.
reference_style_1, reference_style_2 — визуальный стиль, в котором сделать интерфейс.
logo — логотип нашей компании. Разместить в левом верхнем углу.

Перед началом проектирования проанализируй все файлы и требования, задай уточняющие вопросы, и только после получения всех ответов приступай к проектированию интерфейса.

В качестве референса профайлера я скинул несколько скринов из Extended events с изображением окна трассировки, плана запроса и командной панели:

Окно с трассировкой в Extended events
Окно с трассировкой в Extended events

Для проектирования стиля, которому должен соответствовать интерфейс, я скинул референсы из платформы Tantor:

Главное окно платформы Tantor
Главное окно платформы Tantor

После анализа данных Claude задал мне серию вопросов по дизайну, вот некоторые из них:

Уточняющие вопросы от Claude по дизайну
Уточняющие вопросы от Claude по дизайну

После ответа на все вопросы он начал проектирование и через 10 минут выдал мне три варианта стилей:

  • A · Tantor Native — тёплый кремовый фон, бренд‑оранжевый, скруглённые формы (рекомендуемый дефолт);

  • B · Studio Classic — холодные серые тона, плотные строки, прямоугольные углы (приближено к SSMS);

  • C · Pro Dark — тёмный IDE‑стиль для долгих сессий, контрастные подсветки длительности и узлов плана.

A · Tantor Native
A · Tantor Native
B · Studio Classic
B · Studio Classic
C · Pro Dark 
C · Pro Dark 

Варианты отличались только цветовой гаммой. Я выбрал первый вариант Tantor Native. Сам интерфейс Claude спроектировал так, как я и ожидал: командная панель управления трассировкой, фильтры, окно вывода данных трассировки и окно расшифровки строки трассировки.

Далее я подкорректировал несколько элементов в режиме чата:

  1. Объединил кнопки Grouping и Aggregate в одну, так как эти действия связаны.

  2. Убрал поле EVENT, так как у нас, в отличие от MS SQL, оно пока одно — непосредственно выполнение запроса.

  3. Добавил кнопку подключения к серверу СУБД.

  4. Скинул ему файл трассировки, собираемой pg_trace, и он перерисовал вкладку Details согласно имеющейся спецификации полей. Также скинул документацию по данной утилите, чтобы он проверил, что командная панель управления трассировкой соответствует программному интерфейсу pg_trace.

  5. Скинул ему, как работать с API explain.tensor.ru, чтобы он понимал, каким образом мы сможем отобразить план запроса. Мы решили, что визуализировать план будем по кнопке «Vizualize plan», а по дефолту показывать текстовый план запроса в формате json.

В итоге получился вот такой итоговый дизайн:

Далее спроектировали модальные окна управления различными командами.

Подключение к серверу:

Фильтры:

Группировка и агрегация:

Также я описал и технические нюансы, которые на дизайн не влияли:

  • перед стартом трассировки необходимо проверить, существует ли расширение pg_trace и если нет — создать его.

  • Как «слушать» трассировку и готовый python‑скрипт, который может ее разобрать и отдать в нужном нам формате.

Все это позволило Claude собрать полную техническую картину проекта ещё до написания первой строки кода и не переспрашивать по ходу работы.

Чтобы передать все результаты проектирования из Claude Design в Claude Code, нужно выполнить специальный промпт: 'Запусти Handoff to Claude Code'. После этого Claude Design упаковывает все артефакты спроектированного дизайна в единый архив, готовый к загрузке в Code.

После этого он собрал мне архив, я скачал его и больше в Design не возвращался.
Переходим к разработке приложения.

Разработка приложения

В Claude Code я использую набор скиллов Superpowers, который по сути соответствует своему названию и дает следующие возможности:

  • brainstorming — включается до того, как написана первая строчка кода. Помогает разобраться с сырыми идеями через вопросы, рассматривает альтернативы и показывает дизайн по частям, чтобы его можно было обсудить и поправить. В конце сохраняет документ с итоговым дизайном;

  • using‑git‑worktrees — включается после того, как дизайн утверждён. Создаёт отдельное рабочее пространство в новой ветке, настраивает проект и проверяет, что тесты на старте проходят чисто;

  • writing‑plans — включается с готовым дизайном на руках. Разбивает работу на маленькие кусочки — каждый на 2–5 минут. Для каждой задачи: конкретные файлы, готовый код и понятные шаги для проверки;

  • subagent‑driven‑development / executing‑plans — включается, когда план готов. Либо запускает отдельного агента на каждую задачу с двухэтапной проверкой (сначала — соответствие заданию, потом — качество кода), либо выполняет задачи пакетами с остановками для живого ревью;

  • test‑driven‑development — работает во время реализации. Жёстко держит цикл RED → GREEN → REFACTOR: написать падающий тест, убедиться что он падает, написать минимальный код, убедиться что тест проходит, закоммитить. Код без тестов — удаляется;

  • requesting‑code‑review — включается между задачами. Сверяет, что сделано, с планом и сообщает о проблемах с указанием критичности. Критические блокируют движение вперёд;

  • finishing‑a‑development‑branch — включается, когда все задачи закрыты. Проверяет тесты, предлагает варианты дальнейших действий (смёрджить, открыть PR, оставить как есть или удалить ветку) и прибирает за собой рабочее пространство.

Загружаю архив, который в конце своей работы собрал мне Claude Design, и пишу следующий промпт:

Прочитай сначала design_handoff_pg_profiler/CLAUDE.md, затем design_handoff_pg_profiler/README.md. И потом запусти скилл brainstorming

Эти два файла содержали следующие инструкции:

  • CLAUDE.md — короткий промпт‑инструкция для ИИ‑агента: чтó прочитать, в каком порядке, какие требования жёсткие, что в макете мок, а что финальная версия, и каким порядком вести разработку. Это «вход» для агента, по которому он сразу понимает контекст без необходимости перечитывать всё подряд;

  • README.md — полная спецификация проекта для разработчика: дизайн‑токены, архитектура трёх тиров (фронт ↔ WebSocket ↔ unix‑сокет pg_trace), маппинг параметров pg_trace_start(), описание всех экранов и модалок, процедура установки pg_trace на Astra Linux и сценарий smoke‑теста. Это исчерпывающий справочник, к которому возвращаются по мере реализации.

После изучения контента Code оценил масштаб проекта:

Проект большой — CLAUDE.md перечисляет 10 шагов работы, это объём на несколько недель. Засовывать всё в один spec — слишком крупно для качественной проработки. Прежде чем уточнять детали, надо договориться о размере первой итерации.

Claude оценил объём в несколько недель работы. Забегая вперёд, скажу, что реализация заняла 24 часа. Это хорошо иллюстрирует разрыв между тем, как AI оценивает задачи, и тем, насколько эффективно он же выполняет их при правильной декомпозиции.

После этого он начал задавать серию уточняющих вопросов по объему MVP и стеку используемых технологий. Пример:

Я везде выбирал рекомендуемый вариант, поскольку ранее с данными технологиями не работал. В итоге после шести таких вопросов мы зафиксировали следующие решения:

  • Scope: vertical MVP slice (шаги 1, 3, 4, 5 из CLAUDE.md)

  • Backend: Python (FastAPI + websockets), asyncpg

  • Frontend: React + Vite + TypeScript

  • Dev env: WSL2 + локальный PostgreSQL+pg_trace

  • Connection: минимальная Connect‑модалка, без сохранения профилей

  • UI: full chrome, disabled‑состояния для будущих фич

Затем мы перешли к дизайну каждого из этих разделов. Например, раздел по Scope:

Скрытый текст

Раздел 1/6 — Архитектура и границы MVP

Что IN scope для этого spec:

  1. Backend‑скелет на FastAPI: один WebSocket /ws, один HTTP /api/health.

  2. Менеджер подключения к PG: принимает host/port/user/password/sslmode, всегда коннектится к системной БД postgres, резолвит Base name → oid.

  3. Lifecycle pg_trace: проверка установки расширения (3 состояния из README), SET pg_trace.plan_format='json', CREATE EXTENSION IF NOT EXISTS, pg_trace_start(...), pg_trace_stop().

  4. Socket reader: subprocess pg_trace_client.py --format=json --unix-socket=/tmp/pg_trace.sock, парсим JSON из stdout построчно. Порт парсера в нативный Python — следующий spec.

  5. Стриминг событий по WebSocket с типами сообщений из README (event, status, error — без buffer).

  6. UI: header, parameters strip, command panel (только Start/Stop/Clear Data активны), event table (5 колонок), Details inspector (8 секций, Query Plan tab показывает текст плана; кнопка Visualize disabled).

  7. Минимальная Connect‑модалка (без блока saved profiles).

Что OUT of scope (явно):

  • Сохранение профилей подключения (шаг 2)

  • FIFO‑буфер и индикатор Buffer X/Y MB (шаг 6) — вместо этого простой hard‑cap 10 000 событий с прекращением приёма (см. раздел 4)

  • Visualize plan через explain.tensor.ru (шаг 7)

  • Filters modal (шаг 8)

  • Group & Aggregate modal (шаг 9)

  • Auto‑scroll smart defaults, статус‑переходы, error toasts (шаг 10) — кроме базовых

  • systemd unit, journald, packaging под Astra Linux (будет в production‑spec'е, не сейчас)

Структура репо — монорепо:

Раздел 1 ок? Поехали к разделу 2 (Backend internals)?

И так по каждому разделу. Где‑то я вносил свои корректировки, например, пояснил, что корректно останавливать трассировку через SELECT pg_trace_stop(), а не пытаться убить сеанс)

В итоге он составил план из двадцати задач, TDD first.

#

Что

Кол‑во шагов

1

Repo scaffold (Makefile, backend/frontend skeletons)

11

2

/api/health + первый тест

5

3

Error codes + protocol types

6

4

PgClient.check_extension (3-state)

5

5

PgClient.resolve_base/fetch_db_map/set_session_guc

5

6

PgClient.start_trace/stop_trace

5

7

Copy pg_trace_client.py в backend

5

8

TraceReader (subprocess + JSON parser)

5

9

SessionManager (state machine)

5

10

/ws endpoint + session_busy

6

11

Design tokens + globals.css

6

12

TS types (TraceEvent, messages)

3

13

WebSocketClient (3-try reconnect)

5

14

Zustand store

5

15

ConnectionDialog

5

16

Header + ParamsStrip

3

17

CommandPanel + EventTable

3

18

Inspector (Details + Query Plan)

5

19

App.tsx + Toaster + Footer

5

20

End‑to‑end smoke test против реального pg_trace

10

Последним вопросом перед началом разработки был выбор способа исполнения:

  1. Subagent‑Driven (рекомендую) — на каждую задачу свежий subagent в чистом контексте, я ревьюю между задачами. Быстро итерируется, удобно ловить регрессии.

  2. Inline Execution — все задачи в текущей сессии через executing‑plans, батчинг с чекпойнтами. Главное достоинство — контекст не теряется, но context window заполнится быстрее.

Выбрал вариант с субагентами. Реализация заняла почти сутки. Модель — Opus 4.7, параметр Effort выставил в Extra High: это режим максимальных усилий, при котором Claude тратит больше времени на обдумывание каждого шага, генерирует более качественный код, но и токенов расходует значительно больше. Примерно за 40–60 минут исчерпывался пятичасовой лимит использования Claude Pro, после чего приходилось ждать сброса счетчика. В итоге за четыре такие сессии мы реализовали 19 из 20 задач (последнюю задачу решили проверять руками).. На этот момент контекстное окно было заполнено на 43%:

Перед переходом к тестированию я выполнил команду /Compact. Это встроенная команда Claude Code, которая сжимает историю переписки: Claude анализирует все, что было сделано, и заменяет длинный контекст кратким резюме. Это освобождает место в контекстном окне для следующего этапа работы и позволяет агенту не терять фокус на главном:

/compact Сохрани информацию о выполненных нами 19 задачах, и что мы проверяем вручную 20ю. Бекенд мы будем запускать удаленно на моем сервере и ты от меня ждешь ответы на вопросы по тому как мы это будем делать. Список вопросов сохрани. Также у нас проблема с запуском фронтенда и мы ищем способ решения

Отладка приложения


После компакта я перешел к отладке приложения.

Первая проблема, с которой столкнулся была в том, что фронтенд просто не запускался. Как оказалось, не запускался он при включенном VPN. Для меня это не было критично и далее при запуске приложения я просто выключал VPN.

Разработанное приложение запускалось следующим образом: бекенд был установлен на удаленном сервере, где стоял Tantor Postgres 17 с расширением pg_trace, Бекенд поднимался как службаsudo systemctl start pg-profiler-backend. Фронтенд же запускался локально на моем ноутбуке. Для его запуска нужно было выполнить три действия:

  1. Пробросить SSH‑туннель ssh -N -L 8000:127.0.0.1:8000 login@server

  2. Из каталога с фронтендом запустить команду npm run dev

  3. Открыть фронтенд по адресу http://localhost:5173/

И появляется долгожданное окно профайлера:

Первым делом после запуска идет подключение к хосту с PostgreSQL:

Так как я был подключен к удаленному серверу через SSH‑туннель, то задавать хост было не нужно, вместо этого задать домашний каталог пользователя postgres — так спроектировал приложение Code, хотя на стадии дизайна я ожидал, что там будет именно удаленный хост сервера СУБД. Но по факту он сделал правильно. В MS SQL Management Studio профайлер тоже работает внутри выбранного сервера, да и у нас в платформе Tantor все модули работают также внутри инстанса PostgreSQL.

Следующим шагом был запуск трассировки, и тут было несколько ошибок при обращении к программному интерфейсу расширения pg_trace и получению данных трассировки. На исправление ошибок ушло полтора часа, после этого я получил первые данные трассировки:

Вау! Чувствовал себя в знакомой среде, как в MS SQL Management Studio!
После этого я перешел к доработке функций, которые мы не стали делать на этапе MVP.

Реализовали визуализацию плана запроса через API explain.tensor.ru:

Добавили фильтры, чтобы можно было найти в собранной трассировке запрос по конкретной таблице и длительности выполнения:

Добавили возможность применения группировки и агрегации к строкам трассировки:

И результат этого действия:

Добавил также команду экспорта в CSV, хотя в MS SQL я чаще пользовался возможностью выгрузки трассировки в таблицу базы данных. Эта фича была удобной, но реализовывать ее здесь не стал.

Последними реализованными фичами были автоскролл и управление размером трассировки:

Buffer это выбор лимита числа событий в клиенте (по FIFO идет вытеснение старых). А работа автоскролла показана в видеодемонстрации ниже.

Стоит отметить, что оставался один баг, который Claude не смог исправить: при нажатии на кнопку Clear Data должна была происходить очистка таблицы с данными трассировками, но иногда оставалось несколько строк, которые не удалялись и несколько итераций диагностики этого бага результата не дали. Для MVP это некритично, но в продакшн‑версии нужно будет разобраться.

Демонстрация работы профайлера

VK:

Youtube:

Вы можете попробовать работу данного профайлера сами — https://github.com/alex7six/pg‑profiler, инструкция по установке там есть.

Вывод из опыта

На мой взгляд, ИИ не заменяет разработчиков и дизайнеров, но он радикально меняет то, кто может поставить им задачу и в каком виде. Раньше между идеей и ее воплощением стоял длинный коридор: Jira, бриф, Figma, согласование, разработка, правки. Теперь человек с экспертизой в предметной области может самостоятельно дойти до работающего прототипа и прийти к команде не с описанием задачи, а с готовым MVP в руках. Это меняет разговор: вместо 'сделайте мне вот это' получается 'вот как это работает, давайте доведём до продакшна'. Команда дизайнеров и разработчиков получила не техническое задание, а живой инструмент с механикой, нюансами и логикой, которую я как эксперт вложил в него сам.

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