Ошибки в разработке неизбежно повторяются, если после исправления остается только фраза «теперь работает».

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

Работа над True Creator хорошо показала нам разницу между устранением отдельного сбоя и изменением правила, по которому строится система.

Сначала наблюдение, потом объяснение

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

Мы стараемся начинать с того, что можно воспроизвести. При тестировании массового импорта было видно: один Markdown-файл дает семь записей. После сокращения числа заголовков количество записей тоже изменилось. Когда заголовков не осталось, импорт создал одну статью.

Эти три наблюдения позволили сформулировать конкретную проблему: система делила файл по заголовкам.

Мы не стали объяснять ее абстрактным «Markdown работает плохо» и не стали менять содержимое настоящих статей под ограничение инструмента.

Вместо этого закрепили правило: количество записей определяется количеством файлов, а не количеством разделов внутри текста.

Исправить обработчик - задача конкретной реализации. Сохранить правило в спецификации и приемочных сценариях - способ не возвращаться к тому же обсуждению.

У ошибки должен быть измеримый результат исправления

Фраза «исправить импорт» допускает множество трактовок.

Гораздо точнее требование: «Загрузка одного файла с заголовками первого, второго и третьего уровней создает одну запись, сохраняющую все заголовки внутри содержимого».

Такое требование можно проверить. Оно не диктует разработчику выбор библиотеки, но ограничивает допустимый результат.

Аналогично с ошибками интерфейса. Если пользователь видит текст Prisma вместо понятного сообщения, задача состоит не просто в том, чтобы убрать красный блок. Нужно определить ожидаемое поведение при конфликте адреса, недостающем проекте или невозможности открыть запись.

Иначе техническое исключение исчезнет с одного экрана, но появится на другом.

Самые опасные ошибки не всегда заметны

При тестовом импорте мы передали статус DRAFT, то есть черновик. В редакторе же увидели состояние «Опубликовано».

Это не просто косметическое расхождение. Для редакционного продукта статус определяет, может ли текст попасть на публичный сайт.

В подобных ситуациях нельзя сразу утверждать, что виноват импортер: значение могло измениться при сохранении, чтении из базы или отображении в форме. Но правило от этого не меняется. Статус должен сохранять смысл на всем пути от исходного файла до страницы читателя.

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

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

Исправление может обнаружить следующую проблему

Когда массовый импорт перестал дробить статьи на части, появились новые симптомы: сообщение о создании проекта в блоке ошибок, отказ от повторного slug, ошибка редактора при загрузке устаревшей связи tags.

Это не означает, что первое исправление было бесполезным. Оно просто позволило дойти до следующего этапа реального пользовательского сценария.

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

Успешность отдельного запроса и работоспособность процесса - разные вещи.

Еще одна ошибка: проектировать структуру раньше содержания

Не все наши ошибки связаны с программированием.

Когда мы организовали работу над статьями в Google Drive, заранее создали множество папок: проекты, серии, тематические разделы. Система выглядела аккуратной, но для ежедневной работы была неудобной. Большая часть папок оставалась пустой, а навигация становилась все более запутанной.

В итоге мы перенесли 25 подготовленных материалов в общую папку «Черновики», очистили пустую структуру и договорились открывать новые разделы только по реальной потребности.

Это тоже правило, возникшее из ошибки: не создавать сущность лишь потому, что она может когда-нибудь пригодиться.

У него есть практический критерий. Пока нет содержимого и понятного сценария его поиска, новый каталог не нужен.

Как превращать сбои в систему решений

Для себя мы выделяем четыре шага.

Первый - зафиксировать симптом. Что именно происходит, при каких действиях и с какими данными? Скриншот, тестовый файл и последовательность шагов полезнее догадки о причине.

Второй - отделить факт от гипотезы. Наличие ошибки в редакторе еще не доказывает, что неверно сохранились данные. Нужна проверка той части процесса, о которой мы делаем вывод.

Третий - сформулировать правило на уровне продукта. Например, «одна статья имеет одну тему и один проект» или «черновик не показывается публично». Такие правила переживают смену конкретных исполнителей и технологий.

Четвертый - определить критерий приемки. Не «ошибок больше нет», а конкретный сценарий, который должен проходить предсказуемо.

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

Почему этот подход экономит внимание

Часто говорят, что документация нужна разработчикам. На практике она не меньше нужна тому, кто управляет продуктом.

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

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

Это особенно заметно при работе с AI-агентами. Чем меньше неопределенных мест остается в задаче, тем меньше пространства для правдоподобных, но случайных решений.

Ошибки становятся полезными не автоматически

Сам по себе список багов не превращается в экспертную статью и не улучшает систему.

Пользу приносит только завершенный разбор: что мы увидели, что проверили, какой вывод сделали и каким правилом ограничили повторение ошибки.

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

Поэтому мы собираемся рассказывать не только о готовых решениях True Creator. Иногда самая полезная часть истории - то, что сначала мы сделали неправильно, а потом поняли, какое правило должно существовать вместо случайного исправления.