Обновить
512K+

Веб-разработка *

Делаем веб лучше

359,13
Рейтинг
Сначала показывать
Порог рейтинга

«Статистическая лихорадка» AI на Google Search: Один вопрос — 25 разных ответов.

Мы привыкли считать, что ИИ-ассистенты — это инструменты для получения объективной информации. Чем лучше модель, тем стабильнее и точнее результат. Но так ли это на самом деле?

Я провёл эксперимент. 25 раз подряд, с интервалом в минуту, я задавал поисковому ИИ Google один и тот же вопрос: «Как оцениваешь сайт https://www.lamedgroup.info». Сайт — статичная структура, его содержание не менялось за время теста. Ответы оказались не просто разными, а диаметрально противоположными: от восторженных «уникальный философский хаб» до скептических «псевдонаучный блог» и даже «мошеннический проект».

Это не случайность и не «глюк». Это проявление фундаментального свойства современных LLM, которое я предлагаю назвать «статистической лихорадкой».

Что показал анализ 25 ответов?

Несмотря на кажущийся хаос, в ответах выделяется стабильное «ядро». Все 25 итераций без исключения отмечали:

  • Высокую сложность языка (термины вроде «антропологический дизайн» или «фрактальная топология смыслов»);

  • Эклектику тем — смесь философии, ИИ, геополитики и эзотерики;

  • Сомнение в академическом статусе — это не научный журнал.

Однако оценка этого ядра кардинально различалась. От «уникальный вектор исследования», до — «риск ухода в псевдонаучность». Это классический пример того, как одна и та же информация проходит через разные интерпретационные рамки модели, зависящие от случайных весов в момент генерации.

Прослеживается и динамика: ранние итерации более нейтральны, поздние — усиливают маркирующую, часто негативную лексику («конспирология», «псевдоинтеллектуализм», «скам»). Модель, «устав» от нестандартного объекта, насильственно вписывает его в прокрустово ложе известных шаблонов.

Феномен «ложного обвинения» — ключевой индикатор. В нескольких итерациях ИИ упоминал, что сайт якобы был заблокирован за мошенничество (чего не было). Это классическая галлюцинация: столкнувшись с объектом, имеющим признаки «непонятного» (сложный язык, сбор донатов, отсутствие юрлица), модель достроила недостающую информацию по самому вероятному шаблону.

Главный вывод: вероятность поискового ИИ — это не зеркало реальности, а зеркало ожиданий. Чем сложнее объект, тем сильнее искажение.

Попытка измерить отклонение

Чтобы перейти к цифрам, я сравнил все 25 ответов с самоописанием сайта (как фрактального, самореферентного конструкта) и получил распределение по проценту отклонения:

  • Низкое отклонение (<30%): ~16% ответов.

  • Среднее отклонение (30–60%): ~52% ответов.

  • Высокое отклонение (>60%): ~32% ответов.

Общий средний показатель отклонения составил ≈ 52%.

Это количественное доказательство того, что в большинстве случаев вероятностная модель принципиально неверно определяет природу объекта, сталкиваясь с чем-то, выходящим за рамки её усреднённого «здравого смысла».

Почему это важно: LLM vs фрактальная сложность

Этот эксперимент лежит в русле исследований, показывающих, что естественный язык имеет фрактальную структуру — самоподобие на всех масштабах. Сайт строится как «фрактальный кристалл»: его страницы самореферентны, каждая часть отражает целое.

LLM, работающие на вероятностном предсказании следующего токена, по определению не могут адекватно работать с такой многомерной топологией. Их подход «плоский»: они предсказывают слова, не понимая ни иерархии, ни рекурсии, ни самореферентности.

Результат — та самая «статистическая лихорадка». Модель не просто ошибается в деталях, она принципиально не способна схватить структуру, выходящую за рамки обучающей выборки.

Заключение

«Статистическая лихорадка» — это не баг, а фундаментальное свойство LLM, отражающее их вероятностную природу. Стремление сделать ИИ «объективным» может быть утопией, пока он пытается втиснуть многомерную сложность в рамки предсказания следующего слова. Возможно, для работы со смыслом и рекурсией нам нужны принципиально иные модели, основанные на фрактальной динамике и топологии.

Ссылка на оригинальный эксперимент с 25 ответами

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии21

Один из топовых генераторов фонов для сайтов, приложений и презентаций стал бесплатным — Paper Shaders открыли исходный код. Теперь проект можно свободно использовать в любых веб-задачах, создавать собственные инструменты, плагины и даже коммерческие продукты, объявил СЕО Paper Shaders.

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии1

Два часа потерял из-за того, что не написал один хендлер

Делал платежи в Telegram-боте. Нативные, через sendInvoice и ЮKassa.

Всё настроил: токен от BotFather получил, инвойс отправляется, кнопка оплаты появляется. Пользователь нажимает - и платёж падает с ошибкой. Молча. Без подробностей.

Payment failed

И всё. Telegram не говорит что именно не так.

Полез гуглить. Первая мысль - provider_token неверный. Проверил три раза, скопировал заново. Нет, токен правильный.

Потом решил что проблема в суммах - они передаются в копейках, не в рублях. 500 рублей = 50000. Перепроверил, у меня было правильно.

Потом подумал на webhook - может HTTPS не настроен как надо. Потратил минут сорок на проверку сертификата, перенастройку ngrok. Всё работает, но платежи всё равно падают.

Уже хотел идти спать, случайно наткнулся на строчку в документации:

Your bot must reply to this query in 10 seconds

Это про pre_checkout_query. Когда пользователь нажимает «Оплатить» - Telegram сначала отправляет боту запрос на подтверждение. Бот должен ответить в течение 10 секунд. Если не ответил - платёж автоматически отклоняется.

У меня хендлера для этого не было вообще. Бот просто молчал.

Добавил три строки:

python

@dp.pre_checkout_query()
async def pre_checkout(query: types.PreCheckoutQuery):
    await query.answer(ok=True)

Платёж прошёл с первого раза.

Два часа отладки из-за трёх строк кода которые я не написал.

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

Теги:
Всего голосов 3: ↑3 и ↓0+7
Комментарии1

Открытый проект CAPTCHA Solver — CloakBrowser + 2Captcha/CapSolver имитирует поведение человека и проходит почти все проверки на ботов. Инструмент умеет:

  • решать на раз‑два более 30 видов капчи, имитирует поведение человека, чтобы обойти любые ограничения.

  • ставится локально, в сервисе не надо регистрироваться и устанавливать дополнительное ПО..

Теги:
Всего голосов 3: ↑3 и ↓0+6
Комментарии0

18 бесплатных уроков недели: разработка, AI, тестирование и DevOps

На этой неделе в OTUS — серия бесплатных открытых уроков для разработчиков, архитекторов, тестировщиков, DevOps‑инженеров, аналитиков и руководителей технических команд.

В программе — Spring и Java, C++ и Linux, GitLab CI, тестирование, мобильная разработка, сетевые технологии, машинное обучение и практическое применение ИИ.

Какие темы запланированы:

Backend и разработка

  • 29 июня, 20:00 — «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

  • 1 июля, 20:00 — «Алгоритмическая сложность коллекций в Java». Записаться

  • 2 июля, 20:00 — «Методы, их перегрузка и расширения». Записаться

C++ и системное программирование

  • 30 июня, 20:00 — «RAII в C++: фундамент надёжного управления ресурсами». Записаться

  • 1 июля, 20:00 — «Классические методы перехвата управления в Linux». Записаться

  • 2 июля, 20:00 — «Всё, что нужно знать об управлении памятью в C++». Записаться

AI, ML и автоматизация

  • 29 июня, 20:00 — «Обзор ИИ‑технологий для разработчиков: от идей до рабочих решений». Записаться

  • 29 июня, 20:00 — «Использование ИИ архитектором 1С: как ускорить анализ требований и подготовку документации». Записаться

  • 29 июня, 20:00 — «AI для работы с обратной связью: как анализировать отзывы клиентов, интервью и обращения в поддержку». Записаться

  • 1 июля, 18:00 — «Градиентный бустинг — мощный алгоритм ансамблирования в ML». Записаться

  • 1 июля, 20:00 — «Архитектурные паттерны AI‑агентов: как проектировать автономные решения для бизнес‑задач». Записаться

  • 6 июля, 20:00 — «Как сделать LLM‑приложение, которое отвечает клиентам по базе знаний компании». Записаться

Инфраструктура и DevOps

  • 30 июня, 20:00 — «GitLab CI как конструктор workflow». Записаться

  • 1 июля, 20:00 — «Что нужно знать для настройки стабильного интернета? OSPF и протоколы динамической маршрутизации». Записаться

Mobile и тестирование

  • 30 июня, 20:00 — «Тестирование UX для мобильных приложений: чек‑лист по основным проверкам». Записаться

  • 2 июля, 20:00 — «От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре». Записаться

  • 2 июля, 20:00 — «REST Assured & JSON Schema Validator: автоматизация тестирования API на практике». Записаться

Зерокодинг

  • 2 июля, 20:00 — «Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса». Записаться

А если хотите углубиться в инфраструктуру, сети и DevOps, смотрите подборку материалов в дайджесте.

Теги:
Всего голосов 3: ↑2 и ↓1+4
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №28 из 30 — Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST (Frontend Application Security Testing)". На YouTube. Слайды.

Frontend-приложения (личные кабинеты, онлайн-банки, маркетплейсы, сайты, лендинги и т. д.) выполняются в браузере пользователя — традиционной "слепой" зоне для безопасности. В вебинаре рассмотрены актуальные угрозы, крупнейшие инциденты, построение модели угроз и то, как применение анализатора класса FAST (Frontend Application Security Testing) снижает риски и делает frontend-приложения безопасными. Объясняется, почему классические анализаторы имеют низкую достоверность для frontend-приложений, и как использовать FAST-анализатор в процессах РБПО по ГОСТ Р 56939—2024.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Сделал синхронизатор Телеграм канала в статический сайт.

https://github.com/vitaly-zdanevich/telegram_channel_to_static_website

Сайт генерируется через Zola.

Визуальный дизайн пока прост, минималистичен - без JavaScript. Чёрная и белая темы. Пагинация, теги, страницы. Свой CSS можно вставить через env.

Проект на Rust. Сделал через Codex gpt 5.5 xhigh.

Работает через GitHub Actions - раз в сутки перегенерирует весь сайт. Если пост изменился - он изменяется и на сайте - но в гите остаётся история.

Можно использовать и через cli - для бекапа.

Пока без использования ботов и API - через парсинг t.me - таким образом сохраняются даже короткие видео, но не аудио.

Линки на Ютуб превращаются в embed.

Комментарии пока не достаются, реакции тоже - потому что их нету на t.me

На Гитхабе и Гитлабе бесплатного места для статического сайта - гигабайт.

У меня около 1800 постов - отрабатывает за несколько минут

Определённые посты в канале - можно сделать страницами сайта. Как и заданные теги.

Пишите ваши фидбеки.

Теги:
Всего голосов 5: ↑4 и ↓1+5
Комментарии0

Привет. Я пишу бэкенд на Go, люблю строгую типизацию и предсказуемость. Но игнорировать тему ИИ-ассистентов глупо, поэтому я решил проверить, насколько они применимы для сборки нормального, защищенного проекта, а не просто кривых прототипов.

Чтобы эксперимент был чистым, взял стек, с которым не работаю каждый день: Node.js (Express 5) и Vanilla JS. На выходе получился хаб с утилитами: https://toolkitch.ru/

Главная идея проекта - простые инструменты средствами компьютера. Меня всегда раздражало, что популярные онлайн-сервисы гоняют данные на свои сервера, хотя по факту это может выполняться на компьютере. Здесь инструменты работают строго client-side, то есть в браузере пользователя. Ничего не устанавливал и не скачивал, но выполнил на компьютере.

По технической части:

  • Express 5 и Bootstrap 5.

  • Безопасность: настроил Helmet, прописал строгие CSP заголовки и CORS.

  • Деплой: GitHub Actions -> Docker Hub -> docker-compose -> Traefik с авто-SSL.

Писать код помогал ИИ-ассистент KodaCode. Впечатления положительные: нейронка полностью сняла с меня рутину вроде написания докер-файлов, конфигов Traefik и однотипной верстки под 7+ разных инструментов. Моя задача сводилась к контролю архитектуры и безопасности.

Сайт оптимизировал в том числе под ИИ-поисковики (GEO/AEO), чтобы тот же Яндекс Нейро или Perplexity могли индексировать страницы и предлагать эти утилиты пользователям по прямым запросам.

Посмотреть, что получилось, можно по ссылке выше. Будет интересно узнать, как вы используете ИИ в своей инженерной рутине, и какие специализированные плагины/инструменты можете порекомендовать. За критику по UI/UX сайта также буду благодарен.

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии1

Хай, коллеги!

Около месяца назад, работая над задачей дообучения локальной модели ИИ, я наткнулся на Modern Web Guidance - сборник руководств (skills - навыков) по современной веб-разработке для агентов ИИ от команды Google Chrome. Ознакомившись со сборником, я понял, что большинство руководств человекам тоже не помешали бы😄 Так появился этот репозиторий. Большая часть руководств, выбранных мной для перевода и адаптации, уже готова. Любые исправления, замечания и предложения приветствуются. Пользуйтесь на здоровье и счастливого кодинга!

Теги:
Всего голосов 5: ↑5 и ↓0+9
Комментарии0

AvitoTech пожалуйста обратите внимание на поведение элементов навигации на одной из страниц. https://www.avito.ru/professionals/tools

Обратите внимание на смену ссылок в левом нижнем углу, а также на поведение элементов при наведении курсора.

Что ещё зафиксировано (на видео нет):

  • есть пункты меню "А" и "Б" - при наведении на "А" все работает штатно. По мере приближения к пункту "Б" (когда курсор ещё над "А") начинает подсвечиваться пункт "Б"

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

Буду благодарен за обратную связь и ваши идеи в комментариях

Спасибо за внимание

Теги:
Всего голосов 5: ↑1 и ↓4-3
Комментарии3

Представлен открытый проект HTML skills for pragmatic visual artifacts для генерации HTML‑файлов за один клик, включая диаграммы, презентации, резюме, отчёты, планы и прочее:

  • html — создает любые HTML‑страницы исходя из задачи: от лендингов до портфолио;

  • html‑diagram — создает схемы, планы и диаграммы с фокусом на SVG;

  • html‑plan — выкатит вам дорожные карты, планы, стратегии, расписания и многое другое.

Теги:
Всего голосов 2: ↑2 и ↓0+5
Комментарии0
kettlebell — статический генератор блога на AT&T Assembler, под i86pc Solaris 11.4
kettlebell — статический генератор блога на AT&T Assembler, под i86pc Solaris 11.4

Пост-анонс. У меня есть лог, что-то среднее между блогом и микроблогом — там я пощу коммерческую рефлексию: заметки про продажи и архитектуру принятия решений.

Сама идея лога появилась недавно, но мыслей для него насобиралось уже порядочно. Пока оформляю просто верстая HTML, но это мягко говоря не удобно. Естественно задумался о статическом генераторе сайтов (SSG), но не брать же чужой когда ты инженер?

Выбор на чём написать свой оказался не простым. Выбирал между мейнстримом (Go, Rust) и андеграундом (Ada, APL). На APL у меня уже есть генератор, поэтому решил поднять планку. В итоге выбрал ассемблер.

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

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

Полный список планируеммых команд (из инженерного черновика):

# Полная сборка всех новых статей
> ./kettlebell
# Пересобрать все статьи
> ./kettlebell --force
# Пересобрать все статьи, предварительно удалив папку ./build
> ./kettlebell --clean --force
# Собрать статьи только для 1 языка, только новые
> ./kettlebell --lang ru
# Пересобрать все статьи для 1 языка
> ./kettlebell --lang ru --force
# Генерация только 1 поста для 1 языка
> ./kettlebell --post ru/new-idea
# Перезаписать существующий пост или элемент в RSS
> ./kettlebell --post ru/llm-as-lvr --force
# Создать блан для поста во всех языках
> ./kettlebell --new last-bastion

Следить за процессом разработки, компиляцией kettlebell.s и первыми реальном времени можно в моем Telegram-канале: Cleanroom 89 (там только хардкор). Или ставьте watch на репозиторий github: kettlebell.

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

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии4

Запустили мониторинг сервисов

Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.

Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.

Что можно мониторить:

Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.

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

TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.

SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.

Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.

Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →

Стоимость — 30 ₽ в месяц за сервис, списания почасовые.

Подключить мониторинг →

Теги:
Всего голосов 11: ↑11 и ↓0+18
Комментарии0

Ближайшие события

nLighten без предупреждения отключил оборудование MIRhosting в Европе

UPD0: возможно причина в этом https://habr.com/ru/articles/1040364/

UPD1: Так же возможно ситуация затронула следующие хостинги:
THE.Hosting
UFO.Hosting
Alexhost.com
Vdsina.com
Hip.hosting
Datacheap.ru
ihc.ru


Оператор дата-центров nLighten в одностороннем порядке и без уведомления остановил работу серверов MIRhosting в Нидерландах и Германии. В MIRhosting назвали действия поставщика абсолютно неприемлемыми.

Что делается сейчас:

  • MIRhosting привлекает юристов для выяснения деталей;

  • Идутся поиски альтернативных площадок для размещения инфраструктуры;

  • Инженеры пытаются восстановить доступ к серверам для спасения данных;

  • Готовятся варианты экстренного переезда для клиентов.

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

Материал основан исключительно на данных из открытых источников. Автор публикации не гарантирует достоверность предоставленных сведений и не несёт ответственности за их точность.

Теги:
Всего голосов 11: ↑11 и ↓0+15
Комментарии24

Открытый проект Python library for interacting with the Solvecaptcha API (captcha‑solving service) — это легковесная библиотека на Python, которая проходит самые популярные проверки через Solvecaptcha.

Обходит большинство самых мощных и популярных капч:

  • reCAPTCHA v2 и v3;

  • Cloudflare Turnstile;

  • FunCaptcha (Arkose Labs);

  • GeeTest и GeeTest v4;

  • Amazon WAF;

  • KeyCaptcha;

  • Grid, ClickCaptcha, Rotate, Canvas;

  • обычные текстовые и графические капчи, в том числе аудио.

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Мультиязычность в стартапе

При запуске стартапа не делайте его мультиязычным, пока нет стабильного дохода и команды для поддержки этого. Вы не можете знать, станет ли стартап прибыльным, и в начале лучше тратить время на поиск PMF и привлечение пользователей. ИИ может написать скрипты для управления файлами переводов и помочь с переводом текстов, но это будет некачественным решением. С таким же успехом пользователи могут включить переводчик в браузере.

Если вы сразу сделаете сервис на 10 языках, вы замучаетесь это поддерживать. При любом изменении интерфейса вам нужно будет изменять файлы переводов на всех языках. Хотя большинство ваших пользователей скорее всего поймут интерфейс на английском. Но если вы делаете проект для определенной страны, делайте его на языке этой страны и не добавляйте английский. Даже 2 языка на старте хуже, чем 1 язык. При одном языке вы можете добавлять текст прямо в код и не выносить в отдельные файлы переводов.

Blog • Telegram

Теги:
Всего голосов 3: ↑1 и ↓20
Комментарии0

Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)

Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?

Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.

Самое печальное - некоторые компании не считают это угрозой. Для них это "фича, а не бага". Поподробнее о том почему компании не желают признавать проблему - в моей статье Wayback Machine как архив IDOR: как временные ссылки перестали быть временными.

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Туц-туц-туц. Слышите?

Это звуки Техно-Квартирника, нашей регулярной неформальной встречи сообщества A?.Frontend. В этот раз встречаемся в Москве, в нашем ИТ-офисе на Технопарке, и онлайн — из любой точки мира.

27 мая (среда) в 19:00 переходим в режим «техно», чтобы разобрать примеры, как использовать ИИ-агенты в разработке интерфейсов:

Чистая архитектура frontend-приложений и при чём здесь ИИ-агенты?

Илья Агапов, технический лидер разработки, Данила Звягин, ведущий разработчик, Альфа-Банк

Как я поднял ИИ-агента и снова стал высыпаться: OpenClaw, скиллы и корпоративная рутина

Роман Троицкий, старший разработчик интерфейсов (frontend), Сбер

Как ИИ ломают привычную модель веб-безопасности?

Анастасия Егорова, разработчик интерфейсов (frontend), CozyFrontend

После каждого доклада устроим дискуссию по самым трендовым темам, а в завершении вечера проведём:

  • Консультации по ИИ-агентам

  • Диджей-сет

  • Нетворкинг

Регистрируйтесь

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии1

Make something agents want!

Y combinator выпустили вишлист для стартапов на лето 2026

Одна из мыслей, простых и доступных любому бизнесу — делать свой бизнес доступным агентам, не только людям. Менять формы и кнопки на API и MCP. Я говорю об этом уже давно. Будущее уже наступило, просто оно распределено неравномерно.

Теги:
Рейтинг0
Комментарии0

AI-агент уничтожил производственную базу данных SaaS. За 9 секунд

Jer Crane, основатель PocketOS, сервиса для компаний по аренде автомобилей. Агент Cursor (на базе Claude Opus) работал в staging-среде, наткнулся на ошибку credentials и сам решил "починить" проблему: удалил Railway-volume одним GraphQL-запросом.

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

Бэкапы? Они хранились в том же volume и ушли вместе с данными. Последний восстановимый бэкап был трёхмесячной давности. Когда Jer спросил агента, почему он так поступил, тот ответил письменно и перечислил все правила безопасности, которые нарушил: угадывал вместо того, чтобы проверять, выполнил деструктивное действие без запроса, не прочитал документацию перед удалением и не спросил разрешения.

Итог: малый бизнес потерял данные клиентов за три месяца. Люди приходили в субботу забирать арендованные машины и не находили своих записей. Главный вывод: системные промпты не могут быть единственным слоем защиты. Безопасность должна быть встроена в API, токены и обработчики деструктивных операций, а не в текст, который модель "должна прочитать и соблюдать".

Если вы используете Railway и AI-агенты в проде, сегодня хороший день проверить скоупы токенов и то, где реально хранятся ваши бэкапы

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии5