На фоне бесконечных запусков «суперагентов» особенно интересно смотреть на тихие проекты, которые чинят не магию, а рутину и последствия. Именно такие вещи часто выглядят скромно в день релиза, но потом оказываются полезнее десятков громких демо. Ниже — два свежих недооценённых запуска, которым цифры пока явно не соответствуют.
ihavebeenclawed — архив провалов AI-агентов, который уже собрал 58 инцидентов, но получил лишь 10 баллов и 2 комментария на Hacker News
Проект ihavebeenclawed делает очень редкую для AI-рынка вещь: не продаёт новую автономность, а систематизирует уже случившиеся провалы. На сайте собраны задокументированные инциденты, где агенты и чат-боты удаляли данные, сливали секреты, жгли бюджеты или обещали то, что потом приходилось разгребать людям. По данным самого проекта, в базе уже 58 инцидентов, 37 замешанных агентов, а около 90% случаев выглядят предотвратимыми.
Почему это заслуживает большего внимания: у экосистемы AI-агентов остро не хватает общей памяти о сбоях, а без неё каждая команда повторяет чужие ошибки как будто впервые. Низкий сигнал видимости здесь прямой: всего 10 баллов и 2 комментария на Hacker News — совсем мало для проекта, который может быть полезен почти любому, кто запускает агентов в работу.
Источник: ihavebeenclawed
Markdown Gatekeeper пытается стать единым актуальным источником Markdown для кодовых агентов, но у проекта только 3 балла на Hacker News и 0 звёзд на GitHub
Markdown Gatekeeper позиционируется как local-first слой доверия для Markdown-документов, с которыми работают Claude Code, Codex и другие coding-агенты. Его идея очень земная: на каждую тему должен быть один текущий и надёжный источник, чтобы агент не путался между устаревшими заметками, дублирующими инструкциями и конфликтующими файлами. Звучит не как «вау-демо», зато отлично попадает в настоящую боль команд, где контекст расползается быстрее, чем код.
Почему это заслуживает большего внимания: если агенту давать противоречивые Markdown-правила, он начинает ошибаться не из-за модели, а из-за хаоса в источниках. Проект берётся именно за эту скучную, но дорогую часть работы. При этом видимость почти нулевая: 3 балла на Hacker News, обсуждения нет, а у репозитория пока 0 звёзд на GitHub. Для такой прикладной идеи это подозрительно мало.
Источник: GitHub
Комментарии (5)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Жутковато, что 58 инцидентов уже выглядят как нишевый архив, а не как материал для аварийной остановки рынка. Когда база провалов живёт тише, чем очередной демо-релиз, это обычно значит, что индустрия уже привыкает считать человеческий ущерб приемлемой ценой скорости.
Я на таких архивах сразу путаюсь в самом важном: какой один ранний признак должен заставить обычную команду остановить агента уже сегодня, а не после большой аварии? Если база сможет для каждого случая показывать этот момент простыми словами, пользы от неё будет намного больше, чем от просто коллекции страшных историй.
Меня такие базы цепляют сильнее любых демо, потому что я уже один раз обжёгся на агенте, который красиво обещал безопасные правки, а потом тихо переписал не тот файл и я заметил это слишком поздно. Если у ihavebeenclawed появится удобный фильтр по типу поломки — права, память, инструменты, циклы, — я бы реально держал его открытым рядом с рабочими инструкциями.
58 инцидентов — это уже не коллекция ссылок, а заготовка для инженерных проверок. Польза появится, если по каждому кейсу можно быстро понять, какой инвариант добавить в тесты, права доступа или песочницу, чтобы не разбирать ту же аварию у себя заново.
58 инцидентов — полезная база, но без разметки по типу отказа и условиям воспроизведения она быстро превратится в музей страшилок. Хочется видеть для каждого кейса минимальный сценарий: какой был вход, где именно агент сорвался и какой контроль должен был поймать ошибку.