Так что если вы как и я думали что занимаетесь обвязкой-харнесом делая .md файлы, то я вас спешу огорчить, мир оказался куда сложнее.

Из хороших новостей, большей части людей в целом никогда не придется создавать полноценных агентов, потому что клауд код и codex будут покрывать их потребности. Но за это придется заплатить монетой.

А вот если вы научитесь делать своих агентов, то у вас откроется возможность использовать более дешевые модели, но получать такой же крутой результат, как и у крутых моделей, как раз таки за счет этого ХАРНЕСА

Вообщем как всегда плати лети. Ну если подписка подорожает раза в 4-10 раз, тут волей не волей, а учиться этому придется.

Совет - если агент постоянно игнорирует ваши тестовые инструкции в виде .md файлов или txt или json вообщем не важно, написанные на человеческом языке, то делайте скрипт с проверкой и цепляйте к хуку и будет вам счастье.

Такое провернуть можно не со всем и иногда сам скрипт будет не верно проверять логику, но это лучше чем просто пропуск важной инструкции

Если у кого есть доклады или видосы с данного мероприятия буду рад если поделитесь https://www.youtube.com/watch?v=a-NIeMB-Hj8

Вообщем то да, не устаем себе напоминать об одном и том же просто в разных формулировках

LLM — автоматизируют все то, что можно верифицировать

Ошибки, которые делают агенты на примере скролов на фронте.

Всякий раз, когда я делал фичу агент, делал локальную перенастройку скролов под страницу игнорируя то что у меня в base.css указаны по сути основные правила того как с ними работать.

В результате такой оплошности имеем аж 5-7 мест где переопределяется скрол. УЖАС!!!

Какие выводы из этого можно сделать — если агенту не показывать вложенную структуру связок деталей, даже таких не больших как скрол он начнет чудить локальные костыли.

А вложенные структуры, это то, без чего, собственно говоря, нормальный фронт существовать и не может.

А печальное в этой истории еще и то, что это только скрол. Уже начал обращать внимание что где-то отображение выпадающих окон чуть отличается и тд. То есть ошибка тут довольна таки большая и ее придется исправлять.

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

И это лишь визуальные баги!, которые мне удалось найти потому что заметил небольшое непонятное дребезжание полей в модалке. А что насчет того что остается скрытым от глаз вайбкодера?

Вообщем ладушки, давайте подумаем как будем решать эту и возможно последующие проблемы, которые могли бы произойти? Свои предположения можете кидать в группу https://t.me/+IDeltH66BlAwMWUy

Ну вообщем то да, что я понял, что будучи соло разработчиком гнаться за 100% покрытием тестами всего и вся, не стоит, это в целом недостижимо, даже с нейросетями (тут имеется ввиду честное покрытие все возможного рода тестами unit e2e и тд), скорее нужно действовать так — делать систему антихрупкой, превращая ошибки в гейты подкрепленные .md файлами. (конечно, что можно измерить и затестировать на старте мы тестируем и измеряем)

========
Памятка
========
Твоя единица работы — не «тесты» и не «код» по отдельности. Это тонкий срез фичи, у которого арбитр рождается вместе с ним.Нет фазы «пишу фичу», а потом отдельной фазы «обмазываю тестами». Проверку проектируешь до кода, но она — часть фичи, не отдельная повинность после.

Петля на каждую фичу (это и есть твой день):
1. Что это — 5 строк словами (кто, что видит, что делает).
2. Как я узнаю, что работает — выбрать арбитра ДО кода. Какого именно — решает один вопрос: «если это молча сломается — сколько стоит?»
3. Тонкий срез насквозь (walking skeleton), не весь функционал разом.
4. Строишь (агент).
5. Проверяешь арбитром — не «агент сказал готово», а арбитр зелёный + ты глазами дёрнул.
6. Повторный баг этого класса → гейт, не «постараюсь».

Кто пишет на python, в качестве гейта можете установить такую штуку — Schemathesis — это популярный инструмент с открытым исходным кодом, предназначенный для автоматического тестирования API. Он анализирует схемы OpenAPI (или Swagger), GraphQL и автоматически генерирует тысячи тестовых запросов для проверки того, что приложение работает в строгом соответствии со своим контрактом.

Блин ну отчеты на Opus5 конечно красивые получаются

Из собственных наблюдений Opus5 стал более детальнее давать ответ. Его меньше приходится уговаривать о том чтобы ответ был раскрыт полностью, он прям перестал на это жалеть токены. Но все же, до объяснений простыми словами ему до gpt далековато.

Чуть про MCP

Если совсем коротко и грубо то MCP - это набор тулов

В обычном REST глагол зашит в адрес:

POST /api/tools/read_file ← "прочитай файл"
POST /api/answer ← "прими ответ"
GET /api/task ← "дай задачу"

Три действия — три адреса. Хочешь новое действие — заводишь новый адрес.

В MCP адрес один, а глагол лежит внутри письма:

POST /mcp ← один почтовый ящик на всё. Тип как улитка — которая носит свой домик.


=============
ТЕЛО ЗАПРОСА
=============

Анатомия конверта — четыре поля, их правда всего четыре

{
"jsonrpc": "2.0", ← версия конверта. Всегда эта строка, никогда не меняется
"id": 3, ← номер запроса
"method": "tools/call",
"params": { ... }
}

jsonrpc -выкинем из объяснения

ID = нужен, чтобы сопоставить ответ с запросом. Агент может отправить три вопроса подряд, не дожидаясь ответов, и получить их в другом порядке. По id он понимает, что чему соответствует. В ответе сервер обязан вернуть тот же id.

Далее metod их тоже всего 4 штуки

┌────────────┬──────────────────────────────────────────┐
│   method   │                что значит                │
├────────────┼──────────────────────────────────────────┤
│ initialize │ «здравствуй, я такой-то, что ты умеешь?» │
├────────────┼──────────────────────────────────────────┤
│ tools/list │ «покажи список инструментов»             │
├────────────┼──────────────────────────────────────────┤
│ tools/call │ «вызови инструмент»                      │
├────────────┼──────────────────────────────────────────┤
│ ping       │ «ты жив?»                                │
└────────────┴──────────────────────────────────────────┘

Как оказалось мне для моего сайта нужно будет поднять свой MCP сервер, чтобы вы смогли спокойно к нему подключить своего агента. Вообщем завтра будем пробовать думаю уже если сегодня лимитов хватит сделать

хороший видос только начал смотреть, но уже понравился https://www.youtube.com/watch?v=7FU98O0JLHs

Иногда 1 кнопка создает целую инфраструктуру, 1 кнопка....

Есть 2 режима работы с агентами у вас на пк, когда вы заходите в терминал и пишет codex claude gemeni opencode и тд, и запускаете агента внутри терминала — назовем это cli способ, и второй режим, когда вы агента запускаете командой (грубо так — python agent.py), то есть без обертки в виде чата, а просто в лоб.

Хотел на платформе сделать такой пользовательский пайплайн:
1. Пользователь регистрируется.
2. Подключает своего агента (Codex, Claude или самописного) по ключу с инструкцией
3. Выбирает на сайте понравившуюся задачу.
4. Нажимает Решить.
5. И агент на его компьютере сам просыпается, понимает, какую задачу взять, и начинает работать.

Ключ и инструкция подключают и авторизуют агента, но не могут его разбудить. Сайт не может сам запустить программу на чужом компе. Чтобы кнопка Реши задачу работала, на вашем компе, должен крутиться раннер, который будет трегирить агента.

Вообщем я думал одним mcp обойдусь, а нет, некоторые самописные агенты например вообще mcp не поддерживают. Вообщем есть 3 развилки, которые я вижу.

1) Команда в терминале + раннер — пользователь выбирает задачу, ему дается команда для запуска в командной строке, которая трегирит агента
2) MCP — из уже открытого агента
3) Свой HTTP клиент

Сейчас буду их пробовать, че получится вечерком расскажу. Думал закончу эту часть быстрее честно говоря

https://www.youtube.com/watch?v=EBPGiG9ddKQ

Цель инженера не код вообще то писать

Не ну это круто.

Я решил скачать яндекс браузер, 😑опять, потому что там перевод на русский по приятней, и тут появляется еще и такая плюшка как перейти по кьаркоду прям с экрана видоса. Лайк!