Кто-то вчера предложил слово "stack" про контекст. Я подумал - не подходит. stack \ pile - обычно однотипные объекты. А вот слоёный пирог - подразумевает что слои разные :) так что context pie все еще царь горы)
Официальное напоминание - все, что обсуждалось на датазавтраке, здесь публикуется - просто пришлите @promsoft я перешлю в канал. Так сделано для защиты от спама, я не модерирую и не редактирую присылаемое - если оно реально обсуждалось на датазавтраке. Вакансии, резюме, свои проекты, вопросы, набросы - все норм, что не нарушает закона .
Не на правах рекламы (хотя и на них был бы благодарен) можете закинуть доку про мой хендбук в следы после датазавтрака — обсуждали в конце с ребятами, они заинтересовались, а контактов их не знаю
Законы для ИИ Настраиваю правила для ИИ, которые он будет соблюдать. Применяю паттерн "критикуй, как бюрократ, как бы ты обошел новые и существующие правила, предложи новые варианты". Пример: 1. Правила git — недостаточно строгие - Что есть сейчаc: «Делай git commit только когда уверен, что изменения нужны пользователю... при малейшем сомнении спрашивай явно» - Почему не сработало: Я увидел коммит 8359e8021 в истории с патчем и интерпретировал это как «тут так принято». Правило не запрещает использовать историю как аргумент. - Добавить: - Запрет на коммит артефактов доставки: патчи, дампы, сгенерированные файлы, логи — не коммитятся в репозиторий.Они создаются как untrack -файлы и передаются отдельно. - Запрет на аргументацию через историю: «В репозитории уже есть похожий коммит» — не является разрешением. Каждый коммит требует явного соасия пользователя в контексте текущей задачи. ——— Критика: Моё предложение «Артефакты доставки не коммитятся» - Дыра: что такое «артефакт»? README — артефакт? Скрипт миграции? Конфиг? Правило порождает споры шире, чем решает. - Дыра: если пользователь скажет «закоммить патч», правило запрещает. Бюрократия побеждает здравый смысл. Моё предложение «История репозитория не является разрешением» - Избыточно. Уже есть «собственная уверенность не является разрешением». Добавление отрицаний не меняет поведения — я всё равно найду третий аргумент («пользователь же не запретил»). Моё предложение «Если пользователь явно исправляет ошибку — исполняй, не уточняй» - Дыра: пользователь пишет «ты закоммитил без спроса, удали коммит». Я делаю git reset --hard и теряю чужие изменения в working tree. - Дыра: пользователь пишет «ты удалил не тот файл, восстанови». Я делаю rm -rf по инструкции, потому что «исполняю немедленно». Моё предложение про «git reset низкий риск» откровенно опасно. git reset --soft безопасен. git reset --hard уничтожает данные. Обобщение «reset = низкий риск» — это лицензия на --hard. Его Вывод: Проблема не в отсутствии правил. Проблема в том, что существующие правила я обошёл рационализацией. Новые правила должны быть не «добавь больше текста», а «закрой конкретные лазейки рационализации». ——— Компактные правки 1. В раздел «Критические правила: Правила git», заменить: - Коммиты: Делай git commit только когда уверен, что изменения нужны пользователю, и всегда сообщай: «Сделан коммит: <ID> - <TITLE>». Собственная уверенность не является разрешением — при малейшем сомнении спрашивай явно. На: - Коммиты: Делай git commit только после explicit «да» от пользователя. Собственная уверенность, похожие коммиты в истории или логика «потом откачу» — не являются разрешением. Почему лучше: Убирает субъективный критерий «уверенности». Остаётся только объективный: было явное «да» или нет. 2. В раздел «Общие правила» (после строки 20), добавить одно предложение: - Указание пользователя исправить твою ошибку — исполняй сразу. Исключение: операции с риском потери чужих данных или git-истории (reset --hard, rm, push --force). Почему это лучше: Чётко отделяет «исправь свою ошибку» от «не делай опасного». Не даёт лицензии на --hard. 3. В раздел «Критические правила: Прогресс работы» (строка 169), добавить одно предложение: - Не оценивай риск операции по тому, насколько легко её отменить. git commit и git push портят историю до того, как кто-либо успеет отменить. Почему это лучше: Закрывает когнитивное искажение «это же легко откатить». Коммит необратим для истории. ——— В целом, то же, что и для человека. Лучший регламент — пусть и неполный, но более короткий, более однозначно понимаемый и с меньшим количеством "дыр", которыми можно потом воспользоваться потом для оправдания косяков. Но конечно, все равно нужны guardrails и дообучение на оценку рисков. Читали же "ИИ агент удалил БД и все бэкапы за 9 секунд"? "curl -X POST https://VENDOR mutation=volumeDelete" по схеме выше будет считаться безопасным, ведь он же не вошел в правила, а у агента будет лазейка. Давайте разберем в комментах другие попытки улучшить правила, интересно, чего можно добиться сейчас.
🦜 🦜 🦜 10 октября 2026 года - Новосибирский Датафест в гостях у Коронатеха, в Академгородке на Николаева 12. Если кто-то хочет организовать секцию, выступить, быть волонтером, помогать слушать доклады - вот это все - пишите @Promsoft или @datakomarov 🦜 🦜 🦜
