2112

И вот так вот просто сейчас можно сделать все что угодно? А когда у вас уже приложение наберет такие обороты, просто его переписать под большее число пользователей? Просто по сути где-то 10 тыс это же успех разве не так? Ну значит нужно просто мыслить намного НАМНОГО ШИРЕ и покупать подписку за 200$ искать боль решать ее и получать деньги. Вот так просто?

Просто хочу оставить эти первые кадры с данного видоса тут https://www.youtube.com/watch?v=xgkjtF89-44 у меня если че только 3 окна открыто максимум, тут их раза в 4 больше. Уже не раз замечал подобную картину, да чтобы так кодить нужны деньги конечно, но блин, это какое количество проектов в голове так можно держать. Если бездумно и с полным доверием к нейросетям... все равно не понятно Кто нить пробовал one shotом приложение писать, тип просто нашли баг исправили и пошли дальше, без сидов на много тысяч, без замеров в графане и тд. Каков лимит такого доверия??? Тип на какое количество пользователей можно написать хорошее приложение вот так вот делая Plan Act Review Знаете что, как будто бы имеет смысл сейчас делать так, в целом не сильно парится на тему — выдержит ли ваше приложение или нет несколько тысяч запросов в секунду или др нагрузку, а просто делать, изначально в спеке — я делаю приложение на 10 тыс пользовтелей помоги с архитектурой

Я наконец то на своем опыте понял зачем нужен git worktree Вообщем ситуация, я делаю 2 независимые фичи с двумя агентами, каждый в своем окне терминала. Файлы, которые прявят агенты вообще никак не пересекаются, это я прям точно знаю. Но в какие-то моменты то 1 то 2 агент мне начали писать, файлы полностью удалены, ваши изменения исчезли, восстановлю их из контекста. Начал разбираться в чем дело, потому что у меня git checkout команда запрещена и примениться не может. И мало того у меня прописано, что я параллельно делаю несколько фичей и правлю файлы сам бывает, так что мол не лезь в них. И вроде было все ок, до сегодняшнего дня, когда агенты начали писать такое. Вообщем в чем дело — у меня есть тесты, гейты на пре-коммите и они запускаются для всего проекта, если не указать конкретную пачку файлов. Он в какие то моменты понимал что нужно указывать именно те файлы, которые изменил в течении сессии, а иногда делал по другому. Он вместо указании пачки делал git stash — то бишь убирал вообще все новые изменения во всех файлах, кроме тех что он изменил в сессии и гонял проверки. В результате чего у меня агент в параллельной сессии, когда происходил пре-коммит (git stash) на время недоумевал, мол где файлы, где вся работа???? и начинал делать некоторые части заново, потом бах и все возвращалось. В результате, я думаю это немного его сбивало в некоторых моментах. Вот тут то я и вспомнил про git worktree. Просто странно что это произошло только сейчас. Вообщем как то так

https://github.com/colbymchenry/codegraph https://github.com/DeusData/codebase-memory-mcp https://github.com/oraios/serena Есть такая интересная штука как граф памяти хочу попробовать, если кто юзает что то подобное можете в чате поделиться, будет интересно послушать, вообще стоит не стоит, или пусть агент грепает и дальше )

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

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

https://www.youtube.com/watch?v=EBPGiG9ddKQ Цель инженера не код вообще то писать

Иногда 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://agentskills.io/specification

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

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

Чуть про 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 │ «ты жив?» │ └────────────┴──────────────────────────────────────────┘

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

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

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

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

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