Шаг 5: Набросать модель данных

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

Для трекера книг есть одна главная сущность — Book:

Book
- id: unique string
- title: string
- author: string
- status: "to_read" | "reading" | "finished"
- rating: number 1–5 (only if finished)
- addedAt: date

Даже этот крошечный набросок делает решения явными: оценки существуют только для прочитанных книг, статус — одно из трёх фиксированных значений, и у каждой книги есть id. Когда вы передаёте это AI, он перестаёт угадывать имена полей и собирает согласованно.

Причина зафиксировать это пораньше в том, что имена полей просачиваются повсюду. Как только AI напишет код, читающий book.rating, это имя появится в форме, в представлении списка, в слое хранения и в любой добавленной позже функции. Если позволить ему дрейфовать — rating в одном месте, stars в другом, score в третьем — вы получите баги, которые утомительно выслеживать. Модель данных из шести строк — самая дешёвая страховка от этого.

Короткий блок спецификации, готовый к копированию, обычно работает для AI лучше, чем проза. Вот та же модель, записанная как запрос, который вы бы реально отправили:

Use this exact data shape for a book. Don't add fields I didn't list,
and don't rename these:

Book {
  id        — unique string, generated on creation
  title     — string, required
  author    — string, required
  status    — one of: "to_read" | "reading" | "finished"
  rating    — integer 1–5, present ONLY when status is "finished"
  addedAt   — ISO date string, set when the book is added
}

If you think a field is missing, ask me before adding it.

Эта последняя строка — ask me before adding it — делает настоящую работу. Она превращает AI из угадывателя в соавтора и сохраняет модель данных вашей.