Если агент пишет код, то кем становится человек?

[amcured]

А нельзя ли где-нибудь посреди этого фантастического рассказа рассказать три вещи:

▸ какой стек
▸ какой тип задач
▸ где можно посмотреть на получившийся код (или хотя бы проект)

Так-то никаких сомнений в том, что джейсоноукладку на пейтоне или даже тайпскрипте, без новых архитектурных идей и нестандартных решений, без оптимизаций, сделанную для трёх с половиной пользователей — Т9 осилит. А типозависимый парсер CSV на идрисе — нет.

Где на этой шкале ваши задачи?

[skazkin]

Конечно можно

• 100% открытого гитхаба + сам ТАУСИК написал сам себя фактически.

• Всё что представлено в портфолио АО Кибертум (обезличенный список - но проекты вполне себе реальные). Часть из этого же кое-где с ссылками представлены у меня на сайте.

• Мне бы очень хотелось показать так же с нуля воспроизведенный на Rust аналог sing-box/xray-core писавшийся полтора месяца но дух слаб и боится санкций. Но могу дать доступ по желанию.

[amcured]

Ух ты! Спасибо! Раз вы так со всей душой — завтра посмотрю и отпишусь подробно.

аналог sing-box/xray-core

К сожалению, это очень далеко от меня. Я ради знакомства с языком реализовал на расте акторную модель по уму (все авторы библиотек до меня вообще не понимали, что и зачем они пишут) — https://docs.rs/joerl/latest/joerl/ — понял, что раст мне не нравится и забил :)

Удачи вам в любом случае.

[amcured]

Я почитал про TAUSIK и посмотрел на код. Если честно, мне осталось неясно, как именно этот «переводчик с маловнятного на структурированный для AI» может помочь разработчику, знакомому с использованием ассистентов. А условная секретарша не осилит установку.

▸ Почему мне нужен VSCode и IDE? Мне удобно в виме, у меня даже мышки нет.
▸ Делаете ли вы свой RAG?
▸ Что с регрессией, заботятся ли о ней эти инструменты?
▸ Могу ли я вмешиваться в процесс?
▸ Чем это в принципе отличается от глобального правила: «Please treat “Feature: DESCRIPTION” prompt as a request for the new feature, create a plan, clarify all the uncertainties by asking me questions, await for the approvement and implement the plan step by step, finalizing the execution with complete comprehensive tests/documentation update for the new feature, providing a description of what’s been done in a blog post format»?

[skazkin]

На всякий случай акцентирую внимание на том что идеология которую я описываю не предполагает ручного кода вообще. То есть, vim тут предусматривается только как “посмотреть, но не трогать” :)

По пунктам.

1. Для того чтобы следовать SENAR - достаточно даже notepad. Ну а TAUSIK - фреймворк, который требует того или иного IDE или cli - курсор, opencode и т.п.

2. Свой поиск по коду есть, и в предыдущем ответе я был на этом месте неточен. В TAUSIK стоит RAG на FTS5 поверх SQLite, с language-aware чанкингом по границам функций, классов и модулей и инкрементальной переиндексацией по git. Рядом живёт отдельный поиск по базе знаний проекта и по типизированной памяти. Векторных эмбеддингов сознательно нет: на наших объёмах полнотекстовый индекс по умным чанкам даёт более предсказуемый результат, нулевую внешнюю зависимость. Но разве что в новой версии будет shared brain на основе notion - единственный внешний сервис как зависимость.

3. За регрессии отвечают ворота качества, инструмент сам по себе их не ловит. QG-2 не даёт закрыть задачу без выполненных критериев приёмки и хотя бы одного негативного сценария, автоматические проверки на этом шаге обязательны. При работе я делаю регулярный ревью + это заложено в стандарт и как следствие в фреймворк - он верещит если долго не было ревью. Про постепенный архитектурный дрейф в статье сказано честно: никакая память и никакой скилл его до конца не снимают, эта часть по-прежнему ручная.

4. Вмешиваться можно и нужно. S в SENAR это Supervised: на каждом воротом решение принимает человек. До старта агент уточняет непонятные места, план согласовывается, результат проходит приёмку на QG-2. Если оттуда вынуть человека, получится ровно то самое vibe-coding, против которого серия и пишется. Это не золотая пуля где мы кладём, условно, что-то вроде “напиши мне хабр” и идём пить чай - инструментом нужно управлять (не писать код, а писать инструкции, согласовывать задания, осуществлять приёмку) - в этом и есть роль инженера.

5. Про вашу строчку «Please treat Feature: DESCRIPTION…». Это та же интуиция, из которой у меня вырос SENAR, свернутая в одну инструкцию агенту. Работает, пока вы внутри одной фичи, внутри одной сессии и пока дисциплина ещё не просела. Дальше начинаются места, где одной строки мало. Багфиксы, рефакторинги и архитектурные изменения устроены по-другому, у них свои входы и свои критерии. Запись вида очередь по умолчанию никем не слушается в следующей задаче должна сама всплыть рядом с постановкой, а правило в промпте ничего не помнит. Архитектурный дрейф через пятьдесят задач оно не ловит, потому что смотрит только внутрь текущей. И последнее: на тридцать первой задаче за неделю любая личная дисциплина проседает, нужен внешний контур, который шаг пропустить не даёт. Правило в промпте это не ворота, его слишком легко обойти. Полтора года назад у меня тоже было несколько предложений в инструкциях к агенту, SENAR это то, во что они выросли, когда стало видно, где они проседают.

[amcured]

Векторных эмбеддингов сознательно нет: на наших объёмах полнотекстовый индекс по умным чанкам даёт более предсказуемый результат, нулевую внешнюю зависимость.

Очень хорошо понимаю. Я строю RAG для своих нужд по AST, подозреваю, что по тем же самым причинам.

инструмент сам по себе их не ловит

Меня не просили о советах, но я несокрушимо несу добро в массы даже вопреки воле этих масс. Очень тщательно задумайтесь о том, как можно это прикрутить. Это буквально самое главное на длинном пути. Я ловлю архитектурный дрейф хитровывернутым регрессионным анализом в проекте, который весь — один большой архитектурный дрейф (и под капотом там два проекта, на самом деле: https://cure-lang.org)

Вмешиваться можно и нужно […] vibe-coding, против которого серия и пишется

❤

SENAR это то, во что они выросли, когда стало видно, где они проседают

❤

Спасибо за развернутый ответ. Всегда приятно увидеть единомышленика.

[Alex_Burov]

Про 70% problem у Османи — всё так, но я бы добавил один нюанс, который не сразу бросается в глаза.

Оставшиеся 30% не равномерно распределены. Они кучкуются в конкретных местах: граничные условия, обработка ошибок протокола/формата, и архитектурные инварианты (у вас это “архитектурные границы”). Агент уверенно ошибается именно там, потому что эти места редко проговариваются в коде явно — они живут в голове автора как “ну это же очевидно”.

У меня пример из текущего pet-project (CLI для тестирования MCP-серверов): агент генерил обработчики транспорта, тесты зелёные, вручную всё работает. При прогоне на реальных серверах из registry — треть падает с cryptic error. Оказалось, агент везде предполагал, что сервер корректно отвечает на initialize. В реальности — половина серверов в экосистеме MCP возвращают инвалидный или пустой protocolVersion. Этот кейс нигде не был записан в контексте, просто потому что я сам его не знал до того, как прогнал валидатор.

Подписываюсь про “чинить систему, а не код”. Один раз добавил в контекст проекта “всегда предполагай, что peer возвращает мусор на initialize” — с тех пор агент начал генерить defensive парсинг сам.

Но опять же, количество таких проблем можно уменьшить с помощью плагинов/скиллов и подобных workflow для агентных систем, которые будут точечно решать конкретные задачи

[skazkin]

ну да, вот для этого собственно я и напилил SENAR+TAUSIK и продолжаю доработки по второму как минимум. С выходом Opus 4.7 думаю что не я один заметил ухудшение модели - и фреймворк очень сейчас хорошо помогает держать в узде его. На простом примере - сегодня опус на простой задаче споролся - метрику яндекса не смог корректно добавить, вставив правило на eval в nginx . Я сейчас прорабатываю для TAUSIK отдельный маленький shared brain - идея не нова собственно, в большом фреймворке у меня оно работает уже - но для широких масс интеграция с, например, тем же obisidian не помешает явно как уже многие делают.