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

от

Небольшая предыстория: как я сначала НЕ научилась вайб-кодить

Весной 2026 я загорелась вайб-кодингом, даже купила интенсив по вайб-кодингу для продактов. Но к самому интенсиву так и не подготовила окружение: провозилась с VPN, активацией плагина — и неделя интенсива прошла мимо, я только смотрела, как это делают другие.

Потом был воркшоп, где за один заход можно было собрать свой первый продукт. Я не удержалась и взяла задачу посложнее — с базой данных. И на шаге, где эту базу надо было создать, просто встала: не поняла, как это сделать, и остановилась. Так прошли апрель и май — идея «хочу научиться вайб-кодить» была, а движения не было.

С чего всё началось по-настоящему

В начале июня я пришла к моему ИИ со словами «давай повайбкодим» и рассказала несколько рабочих болей системного аналитика.

К тому моменту я перешла в новый проект — большая банковская система: много функциональности, интеграций, несколько канальных приложений, над всем этим работает сразу несколько команд. И почти сразу упёрлась в проблему, знакомую каждому аналитику в большом легаси: целостного описания базы данных нет. Формально оно как бы есть — где-то в одной постановке описана пара таблиц, где-то в другой ещё несколько. Но общей картины — «вот схемы, эта отвечает за то, эта за это, вот таблицы, в них лежит то-то и то-то» — нет вообще. Заходишь в DBeaver и разбираешься каждый раз заново.

Я знала, что внутри БД есть таблицы, в которых хранится информация о схемах, таблицах, полях. И сначала я пришла к ИИ с этим — напиши запрос, который эти данные выведет. Запустила запрос, выгрузила в csv, потом открыла как xls, включила фильтры и какое-то время работала так. Потом появилась новая задача, в постановку добавить описание существующей таблицей. Ну не ручками же это все набивать?..

Поэтому 1я идея для вайбкодинга звучала так: «А можно по моей таблице с описанием базы данных сделать описание базы данных в md формате?».

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

Шаг 1. Описание базы данных уже существует — это метаданные

База данных знает о себе почти всё. Названия схем, таблиц, столбцов, типы, обязательность полей, а иногда и комментарии — всё это лежит в системных представлениях. В PostgreSQL это information_schema и системный каталог pg_catalog.

Запрос (PostgreSQL):

SELECT
    c.table_schema AS schema,
    c.table_name AS table_name,
    obj_description(pc.oid) AS table_comment,
    c.ordinal_position AS pos,
    c.column_name AS field,
    col_description(pc.oid, c.ordinal_position) AS field_comment,
    c.data_type AS type,
    c.is_nullable AS nullable
FROM information_schema.columns c
JOIN pg_catalog.pg_class pc ON pc.relname = c.table_name
JOIN pg_catalog.pg_namespace pn ON pn.oid = pc.relnamespace
                                AND pn.nspname = c.table_schema
WHERE c.table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY c.table_schema, c.table_name, c.ordinal_position;

Результат сохранить в csv.

Шаг 2. Из одного файла — полная документация описания базы данных

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

Кратко:

На входе — csv с данными по запросу.
На выходе — папка с подпапками по схемам, в корне файл md с перечнем таблиц по схемам, в папках по схемам — файлы md по таблицам схемы.

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

Где ИИ не заменил меня (аналитика)

Чтобы не создавать ложного впечатления, что «ИИ всё сделал сам»:

  • Метаданные дают структуру, но не смысл. Запрос вытащит имена и типы, но obj_description/col_description в реальных базах часто пустые. Что конкретное поле значит для бизнеса — в базе не написано. Это по-прежнему работа аналитика: заполнить пустые описания смыслом.
  • Документацию надо поддерживать. В идеале было бы, если бы мне удалось убедить коллег закинуть всю эту информацию в базу знаний проекта и продолжить вести описание БД централизовано через эти страницы. Не удалось. Так родилась еще одна утилита «Описание БД — разница».
  • Точная постановка решает. Утилита получилась с одного захода не потому что «ИИ гений», а потому что задача была узкой и хорошо сформулированной. 2я моя идея была более сложной и работа по ней идет до сих пор (об этом расскажу в отдельной статье).

Что забрать с собой

Если вы аналитик и сидите на такой же «недокументированной» базе:

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

Вывод

Я пришла к ИИ с рабочей болью — и ушла с инструментом. Мне кажется, именно в этом сейчас и есть ценность аналитика, умеющего вайб-кодить: не написать код руками, а точно понять задачу, поставить её и проверить результат. Код теперь — дешёвая часть. Идея и понимание — нет.

Оставьте комментарий