Сухарев / ЙЙ

операционные системы для ии-агентов 😎

это, разумеется, тупизна))

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

ОС это программа, которая управляет ресурсами компа — памятью, процессором и другой фигней — и как апи дает другим программам доступ к этим ресурсам и фигне

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

а звучит, да, прикольно — ai agentic operating system 😱

но эти ОС — это все просто обертки вокруг текстовых моделей, как ЧатГПТ обертка вокруг ГПТ. а зачем вам какая-то обёртка с гитхаба, когда опенйй и антропик уже всё сделали в кодексе и клод коде? правильно, незачем 🤝🤝

Брал обучение Дмитрия с сопровождением. Очень доходчиво и понятно, в том числе, уверен, будет доступно и для людей с нулевыми знаниями в ИТ, так как объясняются не просто принципы работы с ИИ, но и наглядно разжевывается "базовая база" в комфортном повествовании и темпе. Как человек, который рассматривал несколько вариантов приобретения обучения у разных людей, могу сказать уверенно, что технический бэкграунд повествователя и наставника для желающих научиться - ключевой момент. Нет маркетинга и воды (для меня лично), есть просто информация "что и как устроено" и "как работать с моделью", вплоть до важных мелочей. Отличный курс, инструменты и материалы большинству цифровых фантазий зайдут "на отлично". Есть конспекты, что тоже удобно. Все четко, спасибо, приобретением курса точно доволен.

когда вы вайбкодите без заранее заложенных рамок (системных инструкций и аккуратно подобранного стека) как в нашем с вами шаблоне, так сказать от бедра — кодексы и клоды могут начать артхаусом заниматься — копии проекта какие-то создавать на 40ГБ, компоненты на 1000 строк делать, тесты дебильные писать, потом копии этих компонентов делать, копии копий, оставлять легаси реализаций старых "на всякий случай", индексы раньше времени на базу данных накинуть. а вы не знаете, что такое компоненты, индексы и база данных))

🐸

в шаблоне это заложено, но шаблон от всего артхауса не защитит, это надо понимать просто, что там происходит под капотом. все понимать не надо, достаточно понимать концептуально, без деталей реализации, как можно больше идей по чуть-чуть — и в уроках я рассказываю про эти все вечные в разработке вещи — чтобы вы делали 5 шагов вперед, и 2 назад. а не 2 вперед и 1 назад — вайбкодинг это битва, в которой нужно чаще выигрывать, чем проигрывать ©

вот такие штуки хорошо работают:
сразу не пиши код, найди корень проблемы, предложи несколько вариантов решения, оцени каждое от 1 до 10 и рекомендуй наиболее подходящее в данном случае

а если давно диспансеризацию не проводили, где вы модель просите по техдолгу поработать, то вот так делайте через режим планирования /plan, чтобы йй успел подумать хорошенько и вопросы вам задать:
сделай ультра-глубокий ревью, найди тех-долг, выпиши списком его аккуратно и давай в tech_debt/ папку напишем задачи, в формате .md, где максимально подробно опишем все, что нужно выравнять по-уму, весь легаси, рудиментарный код, god-components, покрытие функциональности тестами (можно прям по tdd рефакторить) — чтобы тех-долг весь закрыть.

по приоритету задачи отсортируй.

подготовь списком все задачи, затем запусти саб-агента на ревью (пусть даст оценку от 1 до 10) и выравниваем описание задач (1-2 прохода максимум, основные углы надо закрыть). чем подробнее задачи с подводными камнями описаны, тем лучше. без оверинжиниринга! буквально минимально достаточные правки, чтобы получить максимальный результат в ближайщее время. вторым этапом можешь выделить задачи посложнее, отдельно их обсудим и подумаем, нужно ли их внедрять и почему.

он вам напишет задачи и вы потом в отдельной сессии через /goal запустите их все в работу вот так:
давай по всем задачам в tech_debt/ папке пройдем, все их закроем, после каждой выполненной задачи запускаем саб-агента (без контекста) на код-ревью (пусть даст оценку от 1 до 10) и выравниваем реализацию (1-2 прохода максимум, основные углы надо закрыть), затем отмечаем задачу выполненной, комит/пуш делаем, и переходим к следующей задаче

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

короче, на задачи точно побить тех-долг стоит, чтобы посмотреть сколько его там у вас вообще. а вот что из них делать и как, уже сами в диалоге с моделью решайте, чтобы она на 7 лет на вахту не ушла 🚶‍♀️


и про код-ревью не забывайте

оказывается в заморских рилсах уже полчища обсидиан воинов 🗿 понятно, тема горячая, но чтобы вообще никто не понимал, как это работает и все копировали друг друга это поистине шокирующе))

ничего святого 🇺🇸®

Прошёл курс Дмитрия Сухарева по Vibe-кодингу с помощью Codex, Claude и нейросетей.

Курс мне понравился. Для моего проекта оказался полезным. Ещё понравилось, что видно: Дмитрий сам программист с большим практическим опытом, работал в продуктовой разработке, делал open source проекты. То есть Дмитрий делится рабочим опытом.

Формат удобный: короткие видео, без лекций на несколько часов. Смотришь спокойно, не устаёшь. Если что-то не понял, можно вернуться к нужному куску и пересмотреть. Дмитрий даже по моей просьбе сделал кнопку смотреть с ускорением 1,75.

Во время просмотра было ощущение, что я сижу рядом с Дмитрием, а он показывает, как всё работает. Не просто говорит «найдите такую-то кнопку», а сразу показывает, куда нажимает и зачем. Поэтому сложнее заблудиться или понять что-то неправильно.

По сути, Дмитрий просто ведёт реальную разработку, а ты смотришь за процессом. Вот он ставит задачу, открывает нужное место, ждёт, пока нейросеть закончит работу. Параллельно что-то объясняет, потом возвращается к результату и показывает, что получилось.

Для меня главная ценность была в том, что видно не только что делать, но и как человек думает в процессе. У меня IT-образование, но мало опыта реальной разработки, и курс помог мне увидеть, что это понятный процесс, который мне под силу.

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

В итоге курс дал мне не только инструменты, но и уверенность. Мне стало понятнее, как организовать работу и как не теряться в процессе. Для меня это был ценный опыт. Сергей. @s720054.

🗿

ООоо, я же забыл рассказать это

мега тема 💪

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

вместо этого, в конце задачи просите клод/кодекс:
сделай мне скриншоты всего флоу — от точек входа до разных состояний компонентов.

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

хочу посмотреть реализацию интерфейсов и общую картину — как весь процесс выглядит с точки зрения ui/ux

кодекс сам все переключит, данные создаст в нужных состояниях и тд, а вы сок пьете пока 🧃

потом удобно ему скриншот обратно отправить и попросить внести правки, если он где-то наглупил

upd: в терминале не будет работать, скорее всего клод-код вам куда-то локально в проекте положит эти скриншоты и скажет "смотри их там 👆👈👇", а в кодексе прям в чате отрендерит

Уязвимость реальна и закрыта. Любой пользователь с активной подпиской мог перебирать category_id, создавать транзакции с чужими категориями и читать их названия в своём же списке. Утекали только имена категорий — суммы и даты чужих транзакций оставались недоступны, поэтому severity средняя, а не высокая.

Попутно закрыта дыра пострашнее IDOR: в async-хендлерах не было try/catch, а Express 4 такие ошибки не ловит. Любая невалидная дата или limit=-5 роняли процесс — при restart: always это цикл перезапусков, то есть отказ в обслуживании одним запросом.

И это я еще не все пишу, что Клод нашел, так как он еще не закончил от слова вообще 😂😂😂

говорю же, со всеми бывает:

распространённая ошибка в разработке, когда пользователь А может получить данные пользователя Б, если просто поменяет айди в запросе, например:

вместо /document/123 в строке браузера
запросит /document/124 (просто поменяет айди в ссылке)

называется эта штука indirect object reference, или idor, особенно опасно, когда у вас id инкрементные, а не uuid (а ии любит инкрементные айди 😁)

может быть, помните: в максе вам случайно могли чужой кружок показать 👀

если это был фронтенд, который случайно не тот айди отправлял в бэкенд, то это как раз idor

но это в любом случае ошибка бэкенда — кто бы тебе что ни слал, нельзя давать смотреть чужие кружки — для этого даже код ошибки есть 403 👮

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

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

короче, если вайбкодите, а код читать не умеете и у вас в приложении есть "разные пользователи", проверьте, что они у вас не могут увидеть данные друг друга

промт:
проверь, что у нас в эндпоинтах нет indirect object reference (idor) проблем

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

когда сделаем список — запускай по одному саб-агенту на каждый эндпоинт, пусть сделает код ревью, даст свою оценку и комментарии. если idor есть — пусть чинит через tdd.

затем переходим к следующему эндпоинту в таком же духе, пока не проверим все эндпоинты

/goal