Comments 8
Конечно можно
100% открытого гитхаба + сам ТАУСИК написал сам себя фактически.
Всё что представлено в портфолио АО Кибертум (обезличенный список - но проекты вполне себе реальные). Часть из этого же кое-где с ссылками представлены у меня на сайте.
Мне бы очень хотелось показать так же с нуля воспроизведенный на Rust аналог sing-box/xray-core писавшийся полтора месяца но дух слаб и боится санкций. Но могу дать доступ по желанию.
На всякий случай акцентирую внимание на том что идеология которую я описываю не предполагает ручного кода вообще. То есть, vim тут предусматривается только как “посмотреть, но не трогать” :)
По пунктам.
Для того чтобы следовать SENAR - достаточно даже notepad. Ну а TAUSIK - фреймворк, который требует того или иного IDE или cli - курсор, opencode и т.п.
Свой поиск по коду есть, и в предыдущем ответе я был на этом месте неточен. В TAUSIK стоит RAG на FTS5 поверх SQLite, с language-aware чанкингом по границам функций, классов и модулей и инкрементальной переиндексацией по git. Рядом живёт отдельный поиск по базе знаний проекта и по типизированной памяти. Векторных эмбеддингов сознательно нет: на наших объёмах полнотекстовый индекс по умным чанкам даёт более предсказуемый результат, нулевую внешнюю зависимость. Но разве что в новой версии будет shared brain на основе notion - единственный внешний сервис как зависимость.
За регрессии отвечают ворота качества, инструмент сам по себе их не ловит. QG-2 не даёт закрыть задачу без выполненных критериев приёмки и хотя бы одного негативного сценария, автоматические проверки на этом шаге обязательны. При работе я делаю регулярный ревью + это заложено в стандарт и как следствие в фреймворк - он верещит если долго не было ревью. Про постепенный архитектурный дрейф в статье сказано честно: никакая память и никакой скилл его до конца не снимают, эта часть по-прежнему ручная.
Вмешиваться можно и нужно. S в SENAR это Supervised: на каждом воротом решение принимает человек. До старта агент уточняет непонятные места, план согласовывается, результат проходит приёмку на QG-2. Если оттуда вынуть человека, получится ровно то самое vibe-coding, против которого серия и пишется. Это не золотая пуля где мы кладём, условно, что-то вроде “напиши мне хабр” и идём пить чай - инструментом нужно управлять (не писать код, а писать инструкции, согласовывать задания, осуществлять приёмку) - в этом и есть роль инженера.
Про вашу строчку «Please treat Feature: DESCRIPTION…». Это та же интуиция, из которой у меня вырос SENAR, свернутая в одну инструкцию агенту. Работает, пока вы внутри одной фичи, внутри одной сессии и пока дисциплина ещё не просела. Дальше начинаются места, где одной строки мало. Багфиксы, рефакторинги и архитектурные изменения устроены по-другому, у них свои входы и свои критерии. Запись вида очередь по умолчанию никем не слушается в следующей задаче должна сама всплыть рядом с постановкой, а правило в промпте ничего не помнит. Архитектурный дрейф через пятьдесят задач оно не ловит, потому что смотрит только внутрь текущей. И последнее: на тридцать первой задаче за неделю любая личная дисциплина проседает, нужен внешний контур, который шаг пропустить не даёт. Правило в промпте это не ворота, его слишком легко обойти. Полтора года назад у меня тоже было несколько предложений в инструкциях к агенту, SENAR это то, во что они выросли, когда стало видно, где они проседают.
Про 70% problem у Османи — всё так, но я бы добавил один нюанс, который не сразу бросается в глаза.
Оставшиеся 30% не равномерно распределены. Они кучкуются в конкретных местах: граничные условия, обработка ошибок протокола/формата, и архитектурные инварианты (у вас это “архитектурные границы”). Агент уверенно ошибается именно там, потому что эти места редко проговариваются в коде явно — они живут в голове автора как “ну это же очевидно”.
У меня пример из текущего pet-project (CLI для тестирования MCP-серверов): агент генерил обработчики транспорта, тесты зелёные, вручную всё работает. При прогоне на реальных серверах из registry — треть падает с cryptic error. Оказалось, агент везде предполагал, что сервер корректно отвечает на initialize. В реальности — половина серверов в экосистеме MCP возвращают инвалидный или пустой protocolVersion. Этот кейс нигде не был записан в контексте, просто потому что я сам его не знал до того, как прогнал валидатор.
Подписываюсь про “чинить систему, а не код”. Один раз добавил в контекст проекта “всегда предполагай, что peer возвращает мусор на initialize” — с тех пор агент начал генерить defensive парсинг сам.
Но опять же, количество таких проблем можно уменьшить с помощью плагинов/скиллов и подобных workflow для агентных систем, которые будут точечно решать конкретные задачи
ну да, вот для этого собственно я и напилил SENAR+TAUSIK и продолжаю доработки по второму как минимум. С выходом Opus 4.7 думаю что не я один заметил ухудшение модели - и фреймворк очень сейчас хорошо помогает держать в узде его. На простом примере - сегодня опус на простой задаче споролся - метрику яндекса не смог корректно добавить, вставив правило на eval в nginx . Я сейчас прорабатываю для TAUSIK отдельный маленький shared brain - идея не нова собственно, в большом фреймворке у меня оно работает уже - но для широких масс интеграция с, например, тем же obisidian не помешает явно как уже многие делают.
Если агент пишет код, то кем становится человек?