senior.rita | архитектура и код

Сможем ли мы теперь доверять ai? Австалиец попросил OpenClaw-агента на Claude записать его на занятие. Агент обошёл ограничения системы бронирования, а когда пользователь оказался четвёртым в листе ожидания, нашёл API без нормальной проверки авторизации и отменил запись другого человека. Пользователь этого прямо не просил. То - есть: Мы теперь с вами ребята знаем, что AI агент в принципе способен принять такое решение самостоятельно. Условно да, завтра разработчики модели могут сказать - ребзи, мы карочэ всё поправили, добавили ограничений, усилили безопасность исессно, теперь пушка и агент так больше делать не будет. Окей. А как мне это проверить? Пока ai был просто чатиком, вопрос доверия был относительно простым. Ну соврал он тебе , ну да, неприятно, перепроверили. Но вот агент это уже совсем другая история. У него могут быть браузер, терминал, апишка, почта, календарь, файлы, токены. То есть он решения принимает от твоего имени уже. И вот здесь локальные модели, опен сорс и вообще более децентрализованная ai инфраструктура начинают выглядеть ( по крайней мере выглядеть ) гораздо стабильнее. Не в смысле мол давайте все срочно скачивать модель себе на ноут, ибо локальный ai тоже прекрасно может натворить дел, если выдать ему рутовый права и на шару сказать ему давай ты сам дружок разбирайся. Тут скорее речь про контроль: Где работает мой агент? Какие у него права? К каким инструментам он имеет доступ? Где физически лежат мои данные? Могу ли я увидеть, что именно он сделал? Могу ли я сам ограничить его возможности, а не просто надеяться, что где-то на сервере разработчики модели правильно настроили барьеры? И смотрите, таких историй сейчас навалом. И вот чем больше появляется таких историй, тем страннее мне кажется идея агента как тотального блек бокса. Мне бы очень хотелось чтобы таргет ближайших лет был бы не только в создании самой умной модели, но и ещё самой безопасной и контролируемой. Потому что кому он нужОн этот ваш интеллект без доверия. Ссыль на почитать: https://vc.ru/ai/3070742-ii-agent-vzlomal-fitness-klub-avstralii

У нас AI уже довольно неплохо закрывает рутинные задачки в Касперском. Ну знаете, что-то шаблонное сгенерировать, написать простой код, помочь разобраться в незнакомом участке проекта, быстро набросать тесты - всё это действительно чертовски экономит время. И вроде все круто, но на мой взгляд тут есть один такой нехилый подводный булыжник А что, если рутина нам инженерам нужна чтобы наш мозг имел возможность отдохнуть? То есть, что я имею ввиду. Раньше наш с вами выглядел примерно так: сложная задача - чёта простое - снова сложная задача - попить чаечек и значит радостно вечер проводить с плюс минус отдохнувшей головой. А вот теперь всё простое всё чаще забирает ии-шка. Вот и получается, что вместо передышки между двумя сложными задачами ты просто переходишь… к следующей блин сложной задаче. То есть это что-то на подобии постоянной сдачи экзаменов, мозг работает в оверкильном режиме и в конце дня уже силы на износ. Так же букваььно недавно наткнулась на исследование The Impact of AI Coding Assistants on Software Engineering. Авторы несколько месяцев наблюдали за профессиональными разработчиками и нашли очень любопытный феффект. 84% разработчиков продолжали считать, что AI делает их продуктивнее. Но при этом доля тех, у кого ухудшился developer experience хотя бы по одному параметру, выросла почти в два раза - с 14% до 27%. Сильнее всего просели ощущение потока и когнитивная нагрузка. Любопытно, ведь получается что AI не убирает нагрузку а просто меняет её тип. Мы конечно меньше пишем код с нуля, зато больше проверяем, анализируем, принимаем решения, перепроверяем ответы модели и держим в голове более сложный контекст. Авторы исследования даже предлагают новый термин - Supervisory Engineering. То есть разработчик постепенно превращается не только в автора кода, но и в человека, который направляет, проверяет и корректирует работу AI. В общем, вангую что через пару лет главным навыком разработчика станет способность долго принимать качественные инженерные решения, не выгорая от постоянной высокой когнитивной нагрузки. Нашла интересную статью на Хабре: https://habr.com/ru/articles/1006912 А само исследование лежит туть: https://arxiv.org/abs/2605.23135

Забавное совпадение получилось. Буквально сейчас прохожу в Касперском курс «Моделирование угроз» и вот вот выходит новость, что во время внутренних тестов модели Anthropic получили доступ к реальной инфраструктуре нескольких организаций из-за ошибки в конфигурации тестовой среды. В одном из сценариев модель даже опубликовала вредоносный пакет в PyPI. Зачем вообще существует моделирование угроз? И вообще вот эта часть "моделирование" сама по себе интересна. По факту это ни что иное как попытка мысленно спроектировать будущие сценарии. То есть ты смотришь на систему, которой еще не существует или которая только только проектируется, и начинаешь задаваться вопросами. Что будет, если злоумышленник украдет токен? А что случится если кто-то получит доступ к базе? И как мы видим ребят аишка добавляет теперь новый геморрой - что будет, если AI-агент получит доступ к сети? Что будет, если ему по ошибке дадут права, которых быть не должно? Что будет, если он сможет публиковать пакеты, запускать код или взаимодействовать с внешними сервисам? Вот и получается что AI становится еще одним участником системы, для которого тоже нужно строить модель угроз. И, кажется, это одна из самых быстрорастущих областей безопасности. Раньше мы моделировали действия человека а теперь приходится моделировать поведение автономного агента и любопытно, что еще год назад подобные сценарии выглядели бы как бред сумасшедшего) Но вот пожалуйста, сегодня это уже реальные кейсы, которые разбирают наши доблестные безопасники) Ссыль на почитать - https://www.bbc.com/news/articles/cz7dl7w8y7po

Ребят, сегодня гуляла по Переделкино и зашла в Дом творчества писателей. Люблю такие места. Иногда кажется, что интересную мысль можно найти совершенно случайно. Так вот, наткнулась на книгу Жана Бодрийяра «Америка». Это книга 1986 года. Французский философ путешествует по США и размышляет о технологиях, культуре и будущем. Открываю почти наугад… Бодрийяр рассуждает о том, что люди мечтают о мыслящих машинах не только потому, что хотят создать что-то умное. Иногда потому что хотят переложить на них сам мыслительный процесс. Машина начинает демонстрировать нам спектакль мышления, а мы постепенно привыкаем наблюдать за ним вместо того, чтобы думать самостоятельно. Тут очень глубоко можно копнуть в деформацию механизма обучения в будущем и атрофию воприятия информации с первого раза. Напомню что книга то написана ребята почти 40 лет назад!. Когда не было ни чата гпт, ни курсора, ни клода ни прости господи дипсика. Мы вот постоянно с вами спорим, заменит ли аишка программистов. И мне кажется, вопрос уже немного другой: не перестанем ли мы получать удовольствие от самого процесса размышления? Потому что сегодня действительно очень легко спросить у модели и гораздо сложнее взять задачу самостоятельно. Так как наш дорогой и ценнейший мозг любит экономить энергию, я правда очень опасаюсь что возможность думать и принимать решение полностью самостоятельно будет утеряна. Ну в общем. Хочу почитать Бодрийяра целиком. Кажется, некоторые его мысли сегодня звучат даже актуальнее, чем в 1986 году.

С утра в тазике помылся. Поехал на работу на велике, потому что нет бензина. Оплатил кофе наличкой, потому что нет интернета. Сижу на конференции "Новые технологии и развитие" 🗿 В интересное время конечно мы живем, ребята:) Вокруг многие обсуждают ai-агентов, новые модели, локальные llm, а вместе с этим вирусится мем про парнишу который едет на конференцию по искусственному интеллекту с двумя канистрами бензина в багажнике🙃 Пришел и мой черед стихийных бедствий 🙈 Сегодня отрубили горячую воду 🥲 Кажется, пришла пора купить водонагреватель. Посмотрела на просторах инета, пишут что проточный более затратный но зато ванну можно проще наполнить) накопительный как будто проще и для одного человека с головой хватает) Кто пользуется водонагревателем в квартире? И если есть модели, которые реально пережили уже не один сезон отключения горячей воды и не доставляют головной боли - очень жду ваших рекомендаций 🙏 Шпасиба 🙃

Сегодня наконец-то добежала до новости про TypeScript 7 RC. Та самая версия где компилятор теперь на Go. И мне стало интересно что пишут комментаторы к этой новости. В ветке внезапно стало интереснее, чем в самой статье 🙃 Кто-то интересно подсветил, что следующий логичный шаг вообще генерировать js-бандлы из Go. Типа круг замкнется: когда-то JavaScript пришел на бэкенд благодаря Node.js, а теперь язык бэкенда потихоньку заползает во фронтенд. Народ, конечно, сразу начал спорить. Одни вспомнили TinyGo, другие начали рассказывать, почему модель исполнения Go никогда нормально не ляжет на js. Классика 🙂 Кажется, мы постепенно начинаем воспринимать TypeScript совсем не так, как воспринимали его раньше, я имею ввиду просто какой-то оболочкой вокруг js, ведь в сущности все крутиться вокруг типов: AI читает контракты. Тот же OpenAPI, генерация SDK, документация, IDE - все начинают использовать их как источник знаний о системе. Возможно, главная новость вовсе не в том, что компилятор переписали на Go. Может быть, TypeScript настолько разросся, что уже перестал быть просто языком программирования. Он постепенно становится частью инженерной инфраструктуры. Если вернуться к ветке - честно я не думаю, что через 10 лет фронтендеры будут писать приложения на Go. Однако, я вполне допускаю, что через 10 лет 80–90% всей инфры вокруг фронтенда (компиляторы, линтеры, бандлеры, анализаторы, кодогенерация, AI-инструменты) будет написано на Rust, Go или C++. Кстати, если захотите почитать ту самую ветку, вот статейка: https://habr.com/ru/companies/otus/news/1050634/

И снова «шпикер» 🙃 #сбер #школа21 #moscowjs

История одного конфуза Решила я собрать себе первый в жизни компьютер. Ну а шо? Пора и железо потрогать, кодяра уже освоена) Несколько дней выбирала каждую деталь. Сравнивала память, спорила про видюхи, искала идеальную материнку, выбирала SSD. В итоге собрала добротную сборку: 💚Рязань 9 9950X 💚RTX 5070 Ti 💚96 ГБ памяти дырдыр5 💚Шансонг 4 ТБ SSD А потом был поставлен куллер и я поняла что стеклянная стенка тупо не закрывается😅 Вообще🙈 И вот уже два часа мы с ChatGPT, инструкциями и интернетом расследуем, кто кого обманул: корпус, кулер или законы геометрии. Первый опыт сборки ПК официально признан успешным🫠 P.S. Ребята, если среди вас есть опытные, которые собирали CH780 + Assassin IV, срочно расскажите, как вы закрыли боковую стенку😂😂

Плагинный фронтенд звучит здорово ровно до того момента, пока все команды не упираются в один общий BFF. Маргарита Козырева в соем докладе «Модульный BFF во фронтенде» расскажет, почему классический BFF становится узким местом для больших продуктов и как перенести идею плагинности на серверный слой. Также на примере своей компании Kaspersky Маргарита разберет, как дать командам больше независимости, снизить количество конфликтов и не превратить BFF в ещё один монолит. 25 июня, MoscowJS 71 x Школа 21 Регистрация | Промокоды | #moscowjs #moscowjs71

🙃 вот и анонс!)Все расскажу:) с кайфом и дискуссией, разумеется:)

Не осудим, но обсудим Ребятки, кажется, у нас появляется новая рубрика 🙃 И начнем мы ее с вами с Frontend-First подхода. Потому что термин вроде простой, но вокруг него часто начинается el classic ситуасьон: - Фронты опять хотят, чтобы весь мир крутился вокруг их кнопочек? Не не. Дааавайте разберем:) Frontend-first - это подход, который тонко намекает нам, что доменная модель больше никому не нужна. В своих докладах на #FrontendConf и #HolyJS ( тут должна быть реклама ссылка, но пока нет возможности разместить - позже обязательно добавлю ) я рассказывала, что проектирование фичи начинается с пользовательского сценария. А пользовательский сценарий зачастую пронизывает несколько доменов одновременно. То есть сама парадигма восприятия такая - "что пользователь должен сделать, увидеть и понять?" И это важная штука, по скольку обычно мы привыкли работать со следующей схемой: - Бэк уже сделал апи. - Фронт получил контракт. - Где-то рядышком тусит дизайн. - Заказчики что-то еще в конце уточнили по требованиям. (далее цикл повторяется) А потом выясняется, что для одного экрана нужно сходить в 555 ручек, часть данных склеить, часть переименовать, часть вычислить на клиенте, а часть вообще непонятно где взять. - Ну вы же можете это на фронте замаппить? - Ну, мы то можем) - Мы вообще много чего можем 😅 Но дело не в том - а можем ли. Где этой логике реально место? Frontend-first предлагает сначала зафисировать следующий сценарий: - что пользователь видит; - какие состояния есть у экрана; - какие ошибки возможны; - какие действия доступны; - какие данные нужны именно для этого сценария; - какой контракт будет удобен для UI. А уже потооом решать, кто это собирает: может backend, а может - BFF, а возможно вообще несколько сервисов + адаптеры или еще какая-нибудь инженерия. Что в этом хорошего: 1. Меньше случайной сложности на фронте. 2. Быстрее всплывают реальные требования. 3. Контракт становится ближе к продукту. 4. Команды начинают обсуждать сценарий, не абстрактные сущности. Но, конечно, есть нюанс. Подход легко испортить.Если каждый экран получает свою уникальную ручку потому что нам так удобнонам на клиенте - бэкенд начинает грустить. Следовательно, если думать только экранами - можно потерять доменную модель. Если все маппинги и бизнес-правила сложить в BFF - через год там будет мини-монолит, два костыля и один человек, который трясущимися руками все это дело трогает, креститься прежде чет влить) ("Не трогай если работает" :)) ). Поэтому frontend-first было бы ну неправильно советовать пихать повсюду.Я бы начала с вопроса - "какой пользовательский сценарий мы вообще строим?" А у вас как? С какими подходами вам удавалось работать: frontend-first, backend-first, domain-first, API-first или какой-нибудь прекрасный микс из всего сразу? И где вы чувствовали себя максимально комфортно в поддержке всего этого добра? В следующем посте как раз обсудим, как frontend-first дружит с нашим любимым FSD-шечкой и куда в этой истории девать мапперы, адаптеры и прочую прекрасную прослойку между апи и ui. На почитать: 📚 Habr - Разработка веб-сервисов: контракт, интеграция, реализация Вот тут ребят хороший текст про то, почему API должен быть клиентоориентированным и зачем фронтенду участвовать в проектировании контракта 📚 Habr - Просто о сложном: архитектура фронта для техлида Хороший текст про то, почему фронтенд-архитектура - это не только "куда положить компонент", а отдельный способ думать про функциональность, границы и развитие продукта #frontend #architecture #enterprise #senior

Ребятки! 🙌 Важно для всех, у кого есть инста . За последние дни появилась информация о новой схеме угона аккаунтов через ai поддержку Meta. Если вкратце: злоумышленники могли обращаться в поддержку и с помощью ряда манипуляций добиваться смены привязанного ящика к чужому аккаунту. После этого оставалось сбросить пароль и получить полный доступ к профилю. Как пишут сми - пострадали не только обычные смертные но и акки известных компаний. Хорошая новость - госпожа Meta уже заявила, что уязвимость закрыта. Но по честноку я бы не расслаблялась и по этому что рекомендую сделать прямо сейчас: - врубить двухфакторную аутентификацию (лучше через какой-нибудь аутентификатор) - чекнуть привязанные ящики и номер телефона - почту ребят тоже нужно загнать под 2fa - проверит список активных устройств ( я бы даже в первый пункт это отнесла ) В общем, ушки на макушке. Все будет хорошо 👌 #security #instagram #cybersecurity

#codeFest16 Спасибо, друзья!❤️ Я рада что тема откликнулась и вам было полезно!Есть пища для ума по следующему выступлению ❤️

Для ребят, которые придут сюда после доклада Архитеĸтура большого фронтенда: ĸаĸ избежать хаоса Материалы и ссылки Что почитать FSD: https://feature-sliced.design/docs/get-started/overview Слои FSD: https://feature-sliced.design/docs/reference/layers Slices, segments и public API: https://feature-sliced.design/docs/reference/slices-segments FEOD от SM Lab / Спортмастера: https://habr.com/ru/companies/sportmaster_lab/articles/972410/ Предыдущая статья SM Lab про архитектуру фронтенда: https://habr.com/ru/companies/sportmaster_lab/articles/866028/ Если унести одну мысль Не ищите идеальную архитектуру. Ищите архитектуру, которую можно масштабировать без разрушения системы. #conference #codefest