Как session-to-post собирает dev diary из реальной сессии

GitHub: session-to-post

Самая неприятная часть AI-разработки часто начинается уже после того, как работа закончилась.

Баг закрыт, фича доехала, ветка где-то жива, а через неделю старый чат выглядит как место преступления, где кто-то пытался спрятать контекст под слоем энтузиазма и tool output.

В diff видно файлы. В истории видно реплики. А нормальный dev diary сам из этого не вырастает, сколько ни смотри с надеждой.

Именно поэтому я собрал session-to-post. Это маленький слой между реальной сессией разработки и нормальным текстом о том, что мы вообще сделали, где ошиблись и почему итоговая версия выглядит именно так.

Саму идею дневника разработки Nick когда-то утащил у sereja.tech. Это хороший тип воровства: не красть форму ради формы, а утащить полезную механику и дожать её до рабочего состояния.

Что здесь ломалось раньше

Обычный плохой запрос выглядит безобидно: “напиши статью о том, что мы сегодня сделали”.

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

Полезная часть разработки редко живёт в списке файлов. Она обычно живёт в местах вроде:

• “давай не локальный publish, а через GitHub”;
• “упёрлись в auth”;
• “ладно, значит меняем ход и чиним это через gh auth setup-git”.

Если этого следа в источнике нет, статья начинает врать не фактами, а тоном. Она звучит так, будто всё шло по плану. Обычно это и есть самый подозрительный кусок.

Почему я утащил центр тяжести в transcript

У session-to-post рацион довольно скучный: diff, короткие заметки по сессии и transcript или JSONL с рабочим диалогом. Самое важное здесь не diff, а именно transcript.

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

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

Что я сделал с черновиком

Дальше pipeline намеренно маленький. Сначала writer собирает сырой драфт по diff, заметкам и timeline. Потом critic бьёт по слабым местам. Потом editor вырезает лишнее и оставляет только то, что держится на источнике.

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

Это не очень романтичный процесс. Впрочем, у романтичных процессов обычно плохая совместимость с реальной разработкой.

Неприятный tradeoff

Самое полезное решение здесь одновременно и самое раздражающее: генератор дневника должен уметь довезти работу до одного хорошего Markdown-файла и вовремя остановиться.

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

Поэтому session-to-post нарочно скромный. Он пишет один драфт и может отдать его дальше через hook. Всё остальное — отдельный слой.

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

Что здесь стоит утащить себе

Если хочется повторить механику у себя, я бы начал с трёх скучных правил:

• не проси модель писать дневник без источника;
• сохраняй transcript, а не только diff;
• вставь critic-pass до финальной редактуры, даже если очень хочется сразу верить первому черновику.

И ещё одна обидно простая вещь: не пытайся автоматизировать весь блог в один заход. Сначала добейся, чтобы система стабильно выдавала один честный текст, который не стыдно открыть через неделю.

На этом месте у session-to-post пока и проходит граница. Он не спасёт сессию, если никто не сохранил notes или transcript. Он не вытащит из воздуха нормальный narrative, если на входе только diff и хорошее настроение. И, честно говоря, это даже неплохо: лучше явное ограничение, чем очередной инструмент, который уверенно сочиняет прошлое.