Недельный апдейт Goalrail.
На этой неделе в `origin/main` попало 4 first-parent коммита без merge-коммитов. Небольшая неделя по объему, но полезная по фокусу: меньше "давайте еще одну фичу", больше укрепления контура.
Что сдвинулось.
Во-первых, оформили публичный content operating layer: где живет правда о продукте, где живут Telegram и публикационные артефакты, и почему это не должно смешиваться с runtime или секретами.
Во-вторых, зафиксировали внешний market signal по DeployCo как research material, без автоматического расширения MVP. Это важно: чужой сигнал может быть полезен, но не обязан сразу становиться roadmap.
В-третьих, в execution-контуре добавили smoke coverage для runner capability report. Сейчас это честно только metadata: runner может заявить capability, но это не trusted capability и не unlock для выполнения тестов.
Граница остается прежней: Goalrail еще не исполняет реальные project tests, не делает gate decision и не выпускает proof. На текущем слое мы собираем наблюдаемость и fail-closed receipts до того, как дать системе больше власти.
На этой неделе в `origin/main` попало 4 first-parent коммита без merge-коммитов. Небольшая неделя по объему, но полезная по фокусу: меньше "давайте еще одну фичу", больше укрепления контура.
Что сдвинулось.
Во-первых, оформили публичный content operating layer: где живет правда о продукте, где живут Telegram и публикационные артефакты, и почему это не должно смешиваться с runtime или секретами.
Во-вторых, зафиксировали внешний market signal по DeployCo как research material, без автоматического расширения MVP. Это важно: чужой сигнал может быть полезен, но не обязан сразу становиться roadmap.
В-третьих, в execution-контуре добавили smoke coverage для runner capability report. Сейчас это честно только metadata: runner может заявить capability, но это не trusted capability и не unlock для выполнения тестов.
Граница остается прежней: Goalrail еще не исполняет реальные project tests, не делает gate decision и не выпускает proof. На текущем слое мы собираем наблюдаемость и fail-closed receipts до того, как дать системе больше власти.
Стоимость agent run это уже не только billing.
Раньше стоимость модели легко было воспринимать как закупочную деталь: сколько стоит token, какой лимит, какой тариф.
С coding agents это начинает выглядеть иначе.
Агент может:
• читать большой repo
• долго искать context
• попробовать несколько планов
• запускать tools
• упереться в permission gate
• повторять шаги после failed checks
• сжечь budget на путь, который потом отклонят
• остановиться до proof, потому что закончился лимит
И снаружи все равно может быть ощущение, что работа почти дошла:
PR появился.
Checks какие-то запускались.
Summary звучит нормально.
Но результат не принят.
Proof слабый.
Reviewer снова восстанавливает путь.
А runtime budget уже исчез.
Вот тут cost перестает быть просто "сколько стоил prompt".
Он становится частью receipt.
Мне хочется видеть не только:
"agent finished или нет?"
А еще:
• сколько стоил run
• куда ушли tokens
• сколько было tool calls
• сколько было retries
• где вмешивался человек
• почему run остановился: done, blocked, unsafe или out of budget
• оправдал ли final proof эту стоимость
Потому что полезная единица тут не cost per prompt.
Ближе к правде: cost per accepted change.
Дорогой run не обязательно плохой, если он довел bounded change до нормального proof и approval.
Дешевый run не обязательно дешевый, если после него команда получила review archaeology и переделки.
Для Goalrail это важный слой будущего receipt: не просто что агент сделал, а сколько стоило довести работу до принятого проверенного изменения.
Раньше стоимость модели легко было воспринимать как закупочную деталь: сколько стоит token, какой лимит, какой тариф.
С coding agents это начинает выглядеть иначе.
Агент может:
• читать большой repo
• долго искать context
• попробовать несколько планов
• запускать tools
• упереться в permission gate
• повторять шаги после failed checks
• сжечь budget на путь, который потом отклонят
• остановиться до proof, потому что закончился лимит
И снаружи все равно может быть ощущение, что работа почти дошла:
PR появился.
Checks какие-то запускались.
Summary звучит нормально.
Но результат не принят.
Proof слабый.
Reviewer снова восстанавливает путь.
А runtime budget уже исчез.
Вот тут cost перестает быть просто "сколько стоил prompt".
Он становится частью receipt.
Мне хочется видеть не только:
"agent finished или нет?"
А еще:
• сколько стоил run
• куда ушли tokens
• сколько было tool calls
• сколько было retries
• где вмешивался человек
• почему run остановился: done, blocked, unsafe или out of budget
• оправдал ли final proof эту стоимость
Потому что полезная единица тут не cost per prompt.
Ближе к правде: cost per accepted change.
Дорогой run не обязательно плохой, если он довел bounded change до нормального proof и approval.
Дешевый run не обязательно дешевый, если после него команда получила review archaeology и переделки.
Для Goalrail это важный слой будущего receipt: не просто что агент сделал, а сколько стоило довести работу до принятого проверенного изменения.
Агентные бенчмарки начинают смотреть не только на модель.
IBM Research и Hugging Face выкатили Open Agent Leaderboard:
https://huggingface.co/spaces/open-agent-leaderboard/leaderboard
Самое интересное там, на мой взгляд, не место в таблице.
Интересна рамка: оценивают не просто модель, а всю агентную систему вокруг нее.
Агент это не только LLM. Это инструменты, шаги, контекст, восстановление после ошибки, стоимость и способ провала.
Для разработки это очень близко к нашей теме.
PR есть. Проверки запускались. Описание звучит спокойно.
Но это еще не принятое изменение.
Нужен другой вопрос: довела ли вся система работу до результата, который человек может принять с понятным остаточным риском?
Отдельно зацепила стоимость: неудачные запуски в их экспериментах стоили на 20-54% дороже успешных.
Дорогим становится запуск, который сжег контекст, инструменты, повторы и время ревьюера, но не дал подтверждения результата.
Поэтому мне все больше нравится смотреть не на стоимость одного промпта, а на стоимость принятого проверенного изменения.
Для Goalrail это слой будущего receipt: что агент сделал, сколько это стоило и на каком основании человек может принять результат.
IBM Research и Hugging Face выкатили Open Agent Leaderboard:
https://huggingface.co/spaces/open-agent-leaderboard/leaderboard
Самое интересное там, на мой взгляд, не место в таблице.
Интересна рамка: оценивают не просто модель, а всю агентную систему вокруг нее.
Агент это не только LLM. Это инструменты, шаги, контекст, восстановление после ошибки, стоимость и способ провала.
Для разработки это очень близко к нашей теме.
PR есть. Проверки запускались. Описание звучит спокойно.
Но это еще не принятое изменение.
Нужен другой вопрос: довела ли вся система работу до результата, который человек может принять с понятным остаточным риском?
Отдельно зацепила стоимость: неудачные запуски в их экспериментах стоили на 20-54% дороже успешных.
Дорогим становится запуск, который сжег контекст, инструменты, повторы и время ревьюера, но не дал подтверждения результата.
Поэтому мне все больше нравится смотреть не на стоимость одного промпта, а на стоимость принятого проверенного изменения.
Для Goalrail это слой будущего receipt: что агент сделал, сколько это стоило и на каком основании человек может принять результат.
huggingface.co
Open Agent Leaderboard - a Hugging Face Space by open-agent-leaderboard
The site shows a leaderboard that ranks AI agents across many test environments. Users can filter the models, view a chart that compares accuracy to cost, and download the raw results as a CSV file...
Кажется, канал начал слишком часто крутиться вокруг одной мысли: агент принес результат, но proof и границы все равно остаются на человеке.
Мысль правильная. Но если повторять ее без новых случаев, она превращается в шум.
Поэтому хочу чуть перестроить формат: меньше одинаковых тезисов, больше живых разборов. Взяли задачу, нашли где она расползается, посмотрели какие проверки нужны, зафиксировали что считать proof.
Если у вас есть примеры из своей работы, кидайте в комментарии:
- где агент сделал "почти", но принимать было страшно
- где задача оказалась слишком vague
- где ревью стало дороже после AI
- где не хватило понятного proof
Можно без названий компаний и без приватных деталей. Нужны сами формы поломок.
Из этого и соберем следующие разборы.
Мысль правильная. Но если повторять ее без новых случаев, она превращается в шум.
Поэтому хочу чуть перестроить формат: меньше одинаковых тезисов, больше живых разборов. Взяли задачу, нашли где она расползается, посмотрели какие проверки нужны, зафиксировали что считать proof.
Если у вас есть примеры из своей работы, кидайте в комментарии:
- где агент сделал "почти", но принимать было страшно
- где задача оказалась слишком vague
- где ревью стало дороже после AI
- где не хватило понятного proof
Можно без названий компаний и без приватных деталей. Нужны сами формы поломок.
Из этого и соберем следующие разборы.
У AI-agent repo может быть 50k, 90k, 180k stars.
Это сильный сигнал внимания. Но я бы не принимал его как сигнал надежности.
Stars отвечают на вопрос: сколько людей захотели сохранить repo или хотя бы следить за ним.
Они не отвечают на другие вопросы:
• можно ли повторить пример
• живы ли examples
• что происходит на ошибке
• какие права получает агент
• есть ли нормальный upgrade path
• остается ли после run проверяемый artifact
• сколько human review нужно после результата
Краш-тест простой:
1. Берем обещание из README.
2. Запускаем минимальный сценарий.
3. Смотрим не на красивый output, а на границы: где нужна проверка, где агент может уехать, где человек все равно принимает риск.
4. Фиксируем verdict: можно использовать, только тестировать руками, пока рано.
Хочу попробовать такую рубрику: брать популярные AI repos/tools и разбирать не в логике хороший или плохой, а что их популярность реально доказывает.
Если видели repo, вокруг которого много шума, киньте в комментарии. Можно просто ссылку или название. Возьмем в краш-тест.
Это сильный сигнал внимания. Но я бы не принимал его как сигнал надежности.
Stars отвечают на вопрос: сколько людей захотели сохранить repo или хотя бы следить за ним.
Они не отвечают на другие вопросы:
• можно ли повторить пример
• живы ли examples
• что происходит на ошибке
• какие права получает агент
• есть ли нормальный upgrade path
• остается ли после run проверяемый artifact
• сколько human review нужно после результата
Краш-тест простой:
1. Берем обещание из README.
2. Запускаем минимальный сценарий.
3. Смотрим не на красивый output, а на границы: где нужна проверка, где агент может уехать, где человек все равно принимает риск.
4. Фиксируем verdict: можно использовать, только тестировать руками, пока рано.
Хочу попробовать такую рубрику: брать популярные AI repos/tools и разбирать не в логике хороший или плохой, а что их популярность реально доказывает.
Если видели repo, вокруг которого много шума, киньте в комментарии. Можно просто ссылку или название. Возьмем в краш-тест.
Кажется, у AI-агентов появилась новая боль: им чинят не мозг, а рабочее место.
Увидел несколько свежих маленьких инструментов вокруг агентов для кода. Они смотрят не на то, какая модель умнее, а на грязь вокруг работы:
• dari-docs проверяет, может ли агент выполнить задачу по документации
• PrismoDev ищет мусор в контексте и лишние токены для Claude Code, Codex, Cursor
• Logbox дает агенту нормальный доступ к локальным логам
• Sieve ищет секреты в истории Cursor и Claude
Сами проекты ранние. Это не рекомендация ставить все подряд.
Но сигнал хороший.
Следующий слой зрелости выглядит как гигиена рабочего места: docs, контекст, логи, доступы, история сессий, след для ревью.
Если агент ошибся, часто стоит проверить не только модель.
Может быть, его кормили старыми логами, неактуальными доками, сгенерированными артифактами и пересказами из терминала.
Мини-проверка перед тем, как пускать агента в реальную работу:
1. Что он читает?
2. Что ему нельзя читать?
3. Где он видит логи?
4. Где могут остаться секреты?
5. Можно ли потом восстановить, почему он сделал именно это?
Вот это уже интереснее, чем спорить, какой CLI умнее.
Если у вас всплывали такие поломки - docs, контекст, логи, секреты, история, мусорные артефакты - кидайте в комментарии. Хочу собрать карту AI-workbench hygiene.
Увидел несколько свежих маленьких инструментов вокруг агентов для кода. Они смотрят не на то, какая модель умнее, а на грязь вокруг работы:
• dari-docs проверяет, может ли агент выполнить задачу по документации
• PrismoDev ищет мусор в контексте и лишние токены для Claude Code, Codex, Cursor
• Logbox дает агенту нормальный доступ к локальным логам
• Sieve ищет секреты в истории Cursor и Claude
Сами проекты ранние. Это не рекомендация ставить все подряд.
Но сигнал хороший.
Следующий слой зрелости выглядит как гигиена рабочего места: docs, контекст, логи, доступы, история сессий, след для ревью.
Если агент ошибся, часто стоит проверить не только модель.
Может быть, его кормили старыми логами, неактуальными доками, сгенерированными артифактами и пересказами из терминала.
Мини-проверка перед тем, как пускать агента в реальную работу:
1. Что он читает?
2. Что ему нельзя читать?
3. Где он видит логи?
4. Где могут остаться секреты?
5. Можно ли потом восстановить, почему он сделал именно это?
Вот это уже интереснее, чем спорить, какой CLI умнее.
Если у вас всплывали такие поломки - docs, контекст, логи, секреты, история, мусорные артефакты - кидайте в комментарии. Хочу собрать карту AI-workbench hygiene.
Самое дорогое место в AI-агенте иногда находится до первого действия.
Сегодня проверил в Codex запуск цели через
Снаружи сценарий выглядит правильно: формулируешь цель, агент принимает её и уходит работать.
У меня запуск занял примерно полчаса.
Проблема стала видна только в конце: результат был аккуратный, но не по тому смыслу цели, который я держал в голове.
То есть агент не просто сделал плохо.
Он сделал достаточно близко, чтобы это выглядело как прогресс, и достаточно мимо, чтобы работу пришлось пересобирать.
Вот где для меня начинается реальная цена агентского запуска.
Не в том, что модель ошиблась.
А в том, что до старта не было короткой сверки:
я понял цель вот так;
границы вот такие;
это не трогаю;
готовность проверяем вот этим.
Такой intent check выглядит как задержка на минуту.
Но без него можно спокойно потратить полчаса на выполнение почти той задачи.
Для меня это главный вывод дня: в таких задачах агенту нужен не более быстрый старт.
Иногда ему нужен маленький тормоз перед стартом.
Сегодня проверил в Codex запуск цели через
/goal.Снаружи сценарий выглядит правильно: формулируешь цель, агент принимает её и уходит работать.
У меня запуск занял примерно полчаса.
Проблема стала видна только в конце: результат был аккуратный, но не по тому смыслу цели, который я держал в голове.
То есть агент не просто сделал плохо.
Он сделал достаточно близко, чтобы это выглядело как прогресс, и достаточно мимо, чтобы работу пришлось пересобирать.
Вот где для меня начинается реальная цена агентского запуска.
Не в том, что модель ошиблась.
А в том, что до старта не было короткой сверки:
я понял цель вот так;
границы вот такие;
это не трогаю;
готовность проверяем вот этим.
Такой intent check выглядит как задержка на минуту.
Но без него можно спокойно потратить полчаса на выполнение почти той задачи.
Для меня это главный вывод дня: в таких задачах агенту нужен не более быстрый старт.
Иногда ему нужен маленький тормоз перед стартом.
Goalrail: недельный build note.
На этой неделе в main попало 10 commits. Главный сдвиг не в красивой витрине, а в том, что dogfood-петля стала менее слепой: task -> contract -> work item -> next action теперь проще увидеть из CLI и API.
По продукту продвинули contract-aware planning: proposals больше не выглядят отдельной механикой рядом с целью, а сильнее привязаны к контракту и следующему действию. Появилась деталь WorkItem, next-action packets и более явная handoff-картинка для checkout.
По runtime-слою добавили наблюдаемость вокруг CLI auth refresh и локальный refresh-путь для dogfooding. Это скучная часть, но без нее нельзя честно гонять длинные сценарии: сессия не должна ломать рабочий контекст между шагами.
Публичная поверхность за неделю почти не расширялась. Основной фокус был на внутреннем контуре управления работой и на том, чтобы оператор видел, где сейчас находится задача.
Границы остаются честными: настоящего выполнения, gate decision и proof artifact еще нет. Сейчас Goalrail подтягивает слой подготовки и контроля, прежде чем разрешать системе делать вид, что она уже закрывает delivery end-to-end.
На этой неделе в main попало 10 commits. Главный сдвиг не в красивой витрине, а в том, что dogfood-петля стала менее слепой: task -> contract -> work item -> next action теперь проще увидеть из CLI и API.
По продукту продвинули contract-aware planning: proposals больше не выглядят отдельной механикой рядом с целью, а сильнее привязаны к контракту и следующему действию. Появилась деталь WorkItem, next-action packets и более явная handoff-картинка для checkout.
По runtime-слою добавили наблюдаемость вокруг CLI auth refresh и локальный refresh-путь для dogfooding. Это скучная часть, но без нее нельзя честно гонять длинные сценарии: сессия не должна ломать рабочий контекст между шагами.
Публичная поверхность за неделю почти не расширялась. Основной фокус был на внутреннем контуре управления работой и на том, чтобы оператор видел, где сейчас находится задача.
Границы остаются честными: настоящего выполнения, gate decision и proof artifact еще нет. Сейчас Goalrail подтягивает слой подготовки и контроля, прежде чем разрешать системе делать вид, что она уже закрывает delivery end-to-end.
Один удачный запуск агента слишком легко принять за надежность.
Сценари: меняешь модель, инструкцию, память или доступ к инструментам. Запускаешь задачу. Агент справляется.
В этот момент хочется считать, что схема стала лучше.
Но один запуск показывает только одно: в этих условиях агент дошел до результата.
Он не доказывает, что это повторится.
Не показывает, сколько это стоило.
Не показывает, где стало хуже.
Не показывает, не подстроились ли мы под знакомый пример.
Для себя я бы отделял два вывода.
"Сработало один раз" - сигнал.
"Схема стала надежнее" - утверждение, которое надо проверять.
Мини-проверка перед тем, как выкатывать новый вариант шире:
1. Проверяем не одну задачу, а несколько похожих.
2. Старый и новый вариант получают одинаковые входные данные.
3. Правило приемки одно и то же.
4. На выходе есть проверяемый след: файл, отчет, изменение состояния, список источников или журнал действий.
5. Видны не только успешные случаи, но и поломки.
6. Считаются цена, время и нарушения правил.
Иначе можно улучшить не работу агента, а прохождение одного красивого примера.
Один удачный запуск полезен.
Но как основание для выката - слабовато.
Сценари: меняешь модель, инструкцию, память или доступ к инструментам. Запускаешь задачу. Агент справляется.
В этот момент хочется считать, что схема стала лучше.
Но один запуск показывает только одно: в этих условиях агент дошел до результата.
Он не доказывает, что это повторится.
Не показывает, сколько это стоило.
Не показывает, где стало хуже.
Не показывает, не подстроились ли мы под знакомый пример.
Для себя я бы отделял два вывода.
"Сработало один раз" - сигнал.
"Схема стала надежнее" - утверждение, которое надо проверять.
Мини-проверка перед тем, как выкатывать новый вариант шире:
1. Проверяем не одну задачу, а несколько похожих.
2. Старый и новый вариант получают одинаковые входные данные.
3. Правило приемки одно и то же.
4. На выходе есть проверяемый след: файл, отчет, изменение состояния, список источников или журнал действий.
5. Видны не только успешные случаи, но и поломки.
6. Считаются цена, время и нарушения правил.
Иначе можно улучшить не работу агента, а прохождение одного красивого примера.
Один удачный запуск полезен.
Но как основание для выката - слабовато.
Открыл бету RoleLens.
Это бот не про "разослать резюме в 100 компаний".
Наоборот, мне интересна обратная задача: помочь чаще не нажимать "откликнуться".
Поиск работы сейчас часто ломается не на поиске вакансий, а на фильтрации. Вакансий много, сигнал слабый, каждую нужно руками разобрать: подходит ли роль, живой ли найм, что непонятно, какие риски, что спросить до отклика.
RoleLens берет вакансию и профиль человека и помогает выбрать действие:
откликнуться;
сначала проверить;
сохранить;
пропустить.
Последний пункт важен.
Хороший поиск работы - это не максимум откликов. Это меньше лишних решений и меньше сил на роли, которые с самого начала были мимо.
Попробовать бету: @roleinbox_bot
Функционал пока ограничен. Любые предложения можно оставлять прямо в боте по кнопке "Отзыв".
Это бот не про "разослать резюме в 100 компаний".
Наоборот, мне интересна обратная задача: помочь чаще не нажимать "откликнуться".
Поиск работы сейчас часто ломается не на поиске вакансий, а на фильтрации. Вакансий много, сигнал слабый, каждую нужно руками разобрать: подходит ли роль, живой ли найм, что непонятно, какие риски, что спросить до отклика.
RoleLens берет вакансию и профиль человека и помогает выбрать действие:
откликнуться;
сначала проверить;
сохранить;
пропустить.
Последний пункт важен.
Хороший поиск работы - это не максимум откликов. Это меньше лишних решений и меньше сил на роли, которые с самого начала были мимо.
Попробовать бету: @roleinbox_bot
Функционал пока ограничен. Любые предложения можно оставлять прямо в боте по кнопке "Отзыв".
🔥2
Плохой AI-diff должен умереть до PR.
Не на ревью.
Не после трех кругов CI.
Не когда вся команда уже получила уведомление.
До PR.
Иначе появляется странная сцена:
агент сделал diff;
открыл PR;
CI упал;
агент чинит по логам;
CI снова падает;
reviewer потом получает не чистую работу, а переписку агента с CI.
CircleCI в тексте про Chunk sidecars хорошо подсветили сдвиг: легкие проверки должны жить во внутреннем цикле, пока агент еще работает. CI остается для final-mile проверок: integration, security, release confidence.
Но проверка раньше не значит доказаннее.
Pre-PR validation без receipt - это просто ранний green CI.
Нужен след: что агенту поручили, какой scope он трогал, что запускалось, что падало, что было исправлено и что осталось непроверенным.
Пусть AI-код падает раньше.
Дешевле.
Ближе к задаче.
До того, как черновик стал проблемой всей команды.
Не на ревью.
Не после трех кругов CI.
Не когда вся команда уже получила уведомление.
До PR.
Иначе появляется странная сцена:
агент сделал diff;
открыл PR;
CI упал;
агент чинит по логам;
CI снова падает;
reviewer потом получает не чистую работу, а переписку агента с CI.
CircleCI в тексте про Chunk sidecars хорошо подсветили сдвиг: легкие проверки должны жить во внутреннем цикле, пока агент еще работает. CI остается для final-mile проверок: integration, security, release confidence.
Но проверка раньше не значит доказаннее.
Pre-PR validation без receipt - это просто ранний green CI.
Нужен след: что агенту поручили, какой scope он трогал, что запускалось, что падало, что было исправлено и что осталось непроверенным.
Пусть AI-код падает раньше.
Дешевле.
Ближе к задаче.
До того, как черновик стал проблемой всей команды.
💯1
Goalrail: недельный build note.
На этой неделе в main попал 1 commit. Неделя получилась не про новый экран и не про большой runtime-рывок, а про удержание операционной дисциплины вокруг репозитория.
Главное движение было в слое delivery-гигиены: обновили repo-governance actions до v0.4.0. Это маленький внешний diff, но он держит общий контур проверок ближе к актуальному состоянию shared gate, без локальных обходов в Goalrail.
По продукту границы не расширяли. Контракт, work item, checkout и execution metadata уже есть как прототипный control-plane слой, но это не превращалось на этой неделе в новое обещание для пользователя.
Публичная поверхность тоже без громкого прироста: лучше честно показать тихую неделю, чем выдать maintenance за запуск фичи.
Граница остается прежней: настоящего выполнения проектных команд, gate decision и proof artifact еще нет. Goalrail все еще собирает управляемый путь от задачи к проверяемому результату, не перепрыгивая через недостроенный runtime.
На этой неделе в main попал 1 commit. Неделя получилась не про новый экран и не про большой runtime-рывок, а про удержание операционной дисциплины вокруг репозитория.
Главное движение было в слое delivery-гигиены: обновили repo-governance actions до v0.4.0. Это маленький внешний diff, но он держит общий контур проверок ближе к актуальному состоянию shared gate, без локальных обходов в Goalrail.
По продукту границы не расширяли. Контракт, work item, checkout и execution metadata уже есть как прототипный control-plane слой, но это не превращалось на этой неделе в новое обещание для пользователя.
Публичная поверхность тоже без громкого прироста: лучше честно показать тихую неделю, чем выдать maintenance за запуск фичи.
Граница остается прежней: настоящего выполнения проектных команд, gate decision и proof artifact еще нет. Goalrail все еще собирает управляемый путь от задачи к проверяемому результату, не перепрыгивая через недостроенный runtime.
AI странно влияет на backlog.
Он не просто ускоряет работу.
Он помогает слабым идеям выглядеть прилично.
Раньше часть мыслей умирала на входе.
Не хотелось писать описание.
Не хотелось поднимать контекст.
Не хотелось оформлять задачу, которую потом кто-то должен обсуждать.
Теперь это занимает минуту.
Название есть.
Scope есть.
Risks есть.
Next steps есть.
И вот слабая идея уже выглядит как "ну давай хотя бы посмотрим".
А это дорогая фраза.
Потому что кто-то должен прочитать.
Сравнить.
Отклонить.
Отложить.
Или отдать агенту "быстро попробовать".
Так появляется аккуратный мусор.
Он не выглядит как мусор.
Он выглядит как task candidate.
И именно поэтому его сложнее убить.
Кажется, главный навык работы с AI будет не только в том, чтобы быстро создавать варианты.
А в том, чтобы раньше замечать, какие варианты вообще не должны получать форму.
Плохая идея стала дешевле в упаковке.
Но не дешевле в обслуживании.
Он не просто ускоряет работу.
Он помогает слабым идеям выглядеть прилично.
Раньше часть мыслей умирала на входе.
Не хотелось писать описание.
Не хотелось поднимать контекст.
Не хотелось оформлять задачу, которую потом кто-то должен обсуждать.
Теперь это занимает минуту.
Название есть.
Scope есть.
Risks есть.
Next steps есть.
И вот слабая идея уже выглядит как "ну давай хотя бы посмотрим".
А это дорогая фраза.
Потому что кто-то должен прочитать.
Сравнить.
Отклонить.
Отложить.
Или отдать агенту "быстро попробовать".
Так появляется аккуратный мусор.
Он не выглядит как мусор.
Он выглядит как task candidate.
И именно поэтому его сложнее убить.
Кажется, главный навык работы с AI будет не только в том, чтобы быстро создавать варианты.
А в том, чтобы раньше замечать, какие варианты вообще не должны получать форму.
Плохая идея стала дешевле в упаковке.
Но не дешевле в обслуживании.
На этой неделе у Goalrail тихий основной repo, но не тихий проект.
По заданному weekly-срезу в goalrail origin/main вышло 0 first-parent non-merge commits. Это важно оставить честно: в основном repo не было нового shipped slice, и я не буду превращать отсутствие mainline diff в changelog задним числом.
Но работа шла рядом, в heurema/pactum: за то же окно там 100 commits. Pactum сейчас выглядит как contract-first CLI / execution lab вокруг той же проблемы Goalrail: task -> clarification -> contract -> prompt boundary -> execution -> gate -> review -> memory.
Граница пока такая: Pactum не становится автоматически Goalrail core truth. Goalrail по-прежнему должен владеть contract-to-proof contour, verification, decision и proof, а не превращаться в prompt shell или provider-specific runtime manager.
Поэтому неделя не про паузу, а про развилку. В основном Goalrail repo 0 commits; в соседнем Pactum repo быстро собирался runtime-heavy прототип. Следующий честный шаг - явно решить, что из Pactum остается внешней execution lab, что переносится в Goalrail, а что надо остановить как drift.
По заданному weekly-срезу в goalrail origin/main вышло 0 first-parent non-merge commits. Это важно оставить честно: в основном repo не было нового shipped slice, и я не буду превращать отсутствие mainline diff в changelog задним числом.
Но работа шла рядом, в heurema/pactum: за то же окно там 100 commits. Pactum сейчас выглядит как contract-first CLI / execution lab вокруг той же проблемы Goalrail: task -> clarification -> contract -> prompt boundary -> execution -> gate -> review -> memory.
Граница пока такая: Pactum не становится автоматически Goalrail core truth. Goalrail по-прежнему должен владеть contract-to-proof contour, verification, decision и proof, а не превращаться в prompt shell или provider-specific runtime manager.
Поэтому неделя не про паузу, а про развилку. В основном Goalrail repo 0 commits; в соседнем Pactum repo быстро собирался runtime-heavy прототип. Следующий честный шаг - явно решить, что из Pactum остается внешней execution lab, что переносится в Goalrail, а что надо остановить как drift.
Неделя Goalrail получилась почти без шума: в mainline за окно отчета 0 коммитов. Это тоже часть build-in-public: не притворяемся, что код двигался, если в `origin/main` нет новых first-parent non-merge изменений.
Фокус недели был не в наращивании diff, а в удержании формы продукта. Goalrail остается слоем от бизнес-цели до проверенного изменения: цель, уточнение, контракт, bounded task, receipt, проверка, proof. Важно, что это не IDE и не еще один чат над кодом.
По публичной поверхности картина такая: живут main console/API, `/start` assistant и RU pilot landing. Они уже помогают объяснять продукт снаружи без обещания полного автопилота и без смешивания marketing surface с runtime truth.
По runtime границе все честно: есть prototypes вокруг checkout, execution receipt, project probe и fail-closed project test path. Но реального запуска тестов, gate decision, proof artifact, broad runner trust и полноценного execution loop пока нет.
Главное движение сейчас - не добавлять магии там, где нужна проверяемость. Goalrail должен выглядеть скучнее, чем агентный хайп, потому что ставка здесь на контролируемый delivery loop, а не на красивый статус без доказательств.
Фокус недели был не в наращивании diff, а в удержании формы продукта. Goalrail остается слоем от бизнес-цели до проверенного изменения: цель, уточнение, контракт, bounded task, receipt, проверка, proof. Важно, что это не IDE и не еще один чат над кодом.
По публичной поверхности картина такая: живут main console/API, `/start` assistant и RU pilot landing. Они уже помогают объяснять продукт снаружи без обещания полного автопилота и без смешивания marketing surface с runtime truth.
По runtime границе все честно: есть prototypes вокруг checkout, execution receipt, project probe и fail-closed project test path. Но реального запуска тестов, gate decision, proof artifact, broad runner trust и полноценного execution loop пока нет.
Главное движение сейчас - не добавлять магии там, где нужна проверяемость. Goalrail должен выглядеть скучнее, чем агентный хайп, потому что ставка здесь на контролируемый delivery loop, а не на красивый статус без доказательств.
В Goalrail мы все время возвращаемся к одной границе: агентную работу нельзя принимать только по аккуратному отчету. Нужен договор о том, что считается результатом.
Pactum появился рядом именно для этого - как execution-lab, где можно проверять механику goal -> contract -> execution -> gate -> review до того, как тащить ее в продуктовый канон.
На этой неделе Pactum уперся в ownership validation.
Если executor может менять validation по ходу работы, gate становится слабым местом. Агенту не обязательно закрывать риск задачи - иногда достаточно сделать проверку удобнее.
Поэтому в plan-DAG у Pactum validation живет в approved contract, executor ее запускает, но не авторит, проверка должна быть non-vacuous, а где возможно - baseline-red на pre-change tree.
Например: task чинит CSV export для пустых optional fields. Общий test suite может быть зеленым еще до изменения. Узкая validation по export, которая сначала падает на старом дереве, уже проверяет сам риск задачи.
Это скучная деталь, но именно на ней держится честный agent workflow. Не зеленая строка в отчете, а заранее зафиксированная проверка, которую нельзя ослабить в том же движении, где пишется код.
Pactum все еще не sandbox и не готовый Goalrail runtime. Но как execution-lab он хорошо показывает, где надо ставить контроль: не только на prompt и model choice, а на ownership проверки успеха.
Pactum появился рядом именно для этого - как execution-lab, где можно проверять механику goal -> contract -> execution -> gate -> review до того, как тащить ее в продуктовый канон.
На этой неделе Pactum уперся в ownership validation.
Если executor может менять validation по ходу работы, gate становится слабым местом. Агенту не обязательно закрывать риск задачи - иногда достаточно сделать проверку удобнее.
Поэтому в plan-DAG у Pactum validation живет в approved contract, executor ее запускает, но не авторит, проверка должна быть non-vacuous, а где возможно - baseline-red на pre-change tree.
Например: task чинит CSV export для пустых optional fields. Общий test suite может быть зеленым еще до изменения. Узкая validation по export, которая сначала падает на старом дереве, уже проверяет сам риск задачи.
Это скучная деталь, но именно на ней держится честный agent workflow. Не зеленая строка в отчете, а заранее зафиксированная проверка, которую нельзя ослабить в том же движении, где пишется код.
Pactum все еще не sandbox и не готовый Goalrail runtime. Но как execution-lab он хорошо показывает, где надо ставить контроль: не только на prompt и model choice, а на ownership проверки успеха.
Weekly build note по Goalrail.
За неделю с 15 июня до этого утра в проекте 65 mainline commits: Goalrail repo - 0, Pactum repo - 65.
Goalrail main был тихим, но неделя не была пустой. Работа ушла в Pactum, наш execution-lab и tooling surface для contract-first agentic delivery: там гонялись review loop, usage capture, ACP-only путь, plan-DAG эксперименты, fail-loud поведение и release workflow для native-runner binaries.
Главный сдвиг в механике: меньше магии вокруг агентов, больше измеримой петли contract -> review -> execute -> record. Это пока лабораторная поверхность вокруг Goalrail, а не Goalrail core product truth и не shipped runtime.
Граница остается честной: в самом Goalrail execution, gate, proof generation и полноценный runtime еще не реализованы. На этой неделе проект двигался через Pactum как полигон для будущей дисциплины поставки, пока Goalrail canon/mainline не менялся.
За неделю с 15 июня до этого утра в проекте 65 mainline commits: Goalrail repo - 0, Pactum repo - 65.
Goalrail main был тихим, но неделя не была пустой. Работа ушла в Pactum, наш execution-lab и tooling surface для contract-first agentic delivery: там гонялись review loop, usage capture, ACP-only путь, plan-DAG эксперименты, fail-loud поведение и release workflow для native-runner binaries.
Главный сдвиг в механике: меньше магии вокруг агентов, больше измеримой петли contract -> review -> execute -> record. Это пока лабораторная поверхность вокруг Goalrail, а не Goalrail core product truth и не shipped runtime.
Граница остается честной: в самом Goalrail execution, gate, proof generation и полноценный runtime еще не реализованы. На этой неделе проект двигался через Pactum как полигон для будущей дисциплины поставки, пока Goalrail canon/mainline не менялся.
Слабый тикет агент не чинит. Он просто быстрее превращает его в уверенный дифф.
У человека рядом с задачей есть невидимый слой: старый PR, контекст из Slack, кто будет против, где права доступа, какой нужен откат. У агента этого нет.
Дать ему только "сделать CSV export" - значит попросить угадать остальное. На ревью это потом выглядит не как скорость, а как расследование: почему тронули не тот слой, где проверка прав, кто владелец, чем откатываемся.
Проблема в том, что именно мы отдаем агенту.
Не просто "вот тикет", а пакет: зачем, что не трогаем, какой риск, как проверяем. И рядом то, что агент сам не достанет: похожий PR, контракт, границы доступа, команда теста, кто принимает.
Это выглядит менее эффектно, чем агент, который сам пишет фичу. Но лучше скучная подготовка, чем красивый дифф, который полез в чужой слой.
У человека рядом с задачей есть невидимый слой: старый PR, контекст из Slack, кто будет против, где права доступа, какой нужен откат. У агента этого нет.
Дать ему только "сделать CSV export" - значит попросить угадать остальное. На ревью это потом выглядит не как скорость, а как расследование: почему тронули не тот слой, где проверка прав, кто владелец, чем откатываемся.
Проблема в том, что именно мы отдаем агенту.
Не просто "вот тикет", а пакет: зачем, что не трогаем, какой риск, как проверяем. И рядом то, что агент сам не достанет: похожий PR, контракт, границы доступа, команда теста, кто принимает.
Это выглядит менее эффектно, чем агент, который сам пишет фичу. Но лучше скучная подготовка, чем красивый дифф, который полез в чужой слой.
Агент может задать семь хороших уточняющих вопросов. Цель, сроки, формат, ограничения, тесты, владелец, что не трогать.
А потом на ревью все равно начинается расследование: кто разрешил трогать этот слой, какой сценарий считается сломанным, где граница прав доступа, что является готовностью.
Похоже, тут нет выбора "сначала контекст" или "сначала intent".
На входе нужен черновой intent: что, кажется, пользователь хочет сделать и чего пока не хватает.
Потом короткий проход по контексту: файлы, правила площадки, прошлые решения, ограничения, опубликованные артефакты.
И только после этого вопросы.
Не анкета "уточни все детали", а вопрос из найденного контекста:
"Я вижу два возможных артефакта, какой меняем?"
"В прошлой версии этот слой был вне границы, сейчас это все еще так?"
"Этот шаг трогает права доступа, кто может подтвердить разрешение?"
Intent фиксируется после этой петли: исходный запрос, найденный контекст, оставшиеся разрывы, ответы человека и маршрут.
Intake Contract нужен ровно для этого: проверить, можно ли пускать запрос дальше, кому, с какими границами и какой проверкой.
На ревью это проверяется просто: у вопроса есть источник в контексте, причина и разрыв, который он закрывает.
Если этого нет, вопрос не уточняет работу. Он просто растягивает чат.
А потом на ревью все равно начинается расследование: кто разрешил трогать этот слой, какой сценарий считается сломанным, где граница прав доступа, что является готовностью.
Похоже, тут нет выбора "сначала контекст" или "сначала intent".
На входе нужен черновой intent: что, кажется, пользователь хочет сделать и чего пока не хватает.
Потом короткий проход по контексту: файлы, правила площадки, прошлые решения, ограничения, опубликованные артефакты.
И только после этого вопросы.
Не анкета "уточни все детали", а вопрос из найденного контекста:
"Я вижу два возможных артефакта, какой меняем?"
"В прошлой версии этот слой был вне границы, сейчас это все еще так?"
"Этот шаг трогает права доступа, кто может подтвердить разрешение?"
Intent фиксируется после этой петли: исходный запрос, найденный контекст, оставшиеся разрывы, ответы человека и маршрут.
Intake Contract нужен ровно для этого: проверить, можно ли пускать запрос дальше, кому, с какими границами и какой проверкой.
На ревью это проверяется просто: у вопроса есть источник в контексте, причина и разрыв, который он закрывает.
Если этого нет, вопрос не уточняет работу. Он просто растягивает чат.
Эта неделя в Goalrail получилась не про мелкий changelog, а про смену опоры проекта.
Окно отчета: 22-27 июня. Project-wide счет: 56 mainline commits: Goalrail repo - 40, Pactum repo - 16.
В Goalrail mainline переехал на новый корень и начал превращать прежний Omnigent runtime в Goalrail-facing surface: команды, onboarding, help, runtime paths, config/data home, public docs и app copy стали говорить одним именем.
Pactum двигался рядом как execution-lab/tooling surface для contract-first agentic delivery. Там убрали лишний project map/search слой, перевели guardrails ближе к git truth, починили git-guard edge cases и сделали reviewer parse misses fail loud вместо тихого прохода.
По outcome это неделя выравнивания: Goalrail получил более цельную публичную и runtime-обвязку, Pactum снизил шанс, что агентная попытка выглядит принятой без проверяемого контракта.
Граница остается честной: execution, gate, proof и runtime-кусочки еще не надо считать реализованной Goalrail core product truth. Сейчас это сборка поверхности и лабораторной дисциплины вокруг нее, с явной подписью человека под результатом.
Окно отчета: 22-27 июня. Project-wide счет: 56 mainline commits: Goalrail repo - 40, Pactum repo - 16.
В Goalrail mainline переехал на новый корень и начал превращать прежний Omnigent runtime в Goalrail-facing surface: команды, onboarding, help, runtime paths, config/data home, public docs и app copy стали говорить одним именем.
Pactum двигался рядом как execution-lab/tooling surface для contract-first agentic delivery. Там убрали лишний project map/search слой, перевели guardrails ближе к git truth, починили git-guard edge cases и сделали reviewer parse misses fail loud вместо тихого прохода.
По outcome это неделя выравнивания: Goalrail получил более цельную публичную и runtime-обвязку, Pactum снизил шанс, что агентная попытка выглядит принятой без проверяемого контракта.
Граница остается честной: execution, gate, proof и runtime-кусочки еще не надо считать реализованной Goalrail core product truth. Сейчас это сборка поверхности и лабораторной дисциплины вокруг нее, с явной подписью человека под результатом.