Я работаю проджект‑менеджером в крупной IT‑компании. Я за вечер сделал то, на что раньше ушло бы несколько месяцев работы целой команды. И этот опыт полностью поменял мое отношение к роли разработчика.
Действия ИИ-агента в браузере через скриншоты и клики — минута и десятки центов. Через WebMCP — секунды и доли цента. Два порядка разницы.
Так что же под этим черновиком стандарта WebMCP и куда он нас ведёт?
Делимся рабочим рецептом: SEO‑блог на 84 страницах в трёх языках (RU/KK/EN) через Claude API за три дня. Внутри — почему мы храним статьи как TypeScript‑объекты вместо Markdown, как собрать system prompt на 360 строк, чтобы Claude корректно ставил internal‑ссылки, как генерим уникальные OG‑обложки через Gemini + PIL, и где AI стабильно косячит те 30% работы, которые всё равно делает человек.
Мы живём в эпоху смены парадигмы взаимодействия человека с сетевыми системами, смены того, как люди подтверждают то, что они те, за кого себя выдают. Главные вопросы, которые всегда задавали пользователям, звучали так: «Что вы знаете?» (пароль, PIN-код, девичья фамилия матери), или «Как вы выглядите?» (Face ID, отпечатки пальцев). Теперь же на первый план выходит такой вопрос: «Как вы себя ведёте?».
В наши дни развитие генеративного ИИ и прогресс в разработке вредоносного ПО, вроде RAT (Remote Access Trojan, троян удалённого доступа), позволили киберпреступникам проводить широкомасштабные атаки и даже обходить такие механизмы безопасности, как Face ID или MFA (Multi-Factor Authentication, многофакторная аутентификация, МФА), которые ранее считались «пуленепробиваемыми».
В наши дни анализ поведенческой биометрии становится стандартным подходом к обеспечению безопасности в банках, ответственных за покрытие убытков от киберпреступлений. Этот подход используется в тех случаях, когда внедрённые банками меры безопасности не способны гарантировать защиту от проблем, характерных для новых схем мошенничества.
Продолжение прошлой статьи про ошибки на Go-собесах. В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”.
Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26.
Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.
Я раньше был уверен, что понимаю, как работает отслеживание в интернете. Очистил cookies - чист. Включил VPN - спрятался. Поставил блокировщик - стал почти невидимым. Звучит логично, правда?
Проблема в том, что всё это работает только на уровне, который уже давно не является основным.
Современные сайты не обязательно знают, кто ты. Им это и не нужно. Достаточно собрать достаточно признаков, чтобы отличить тебя от всех остальных. Версия браузера, разрешение экрана, поведение мыши, особенности рендеринга графики, сетевые характеристики - по отдельности это просто параметры. Но вместе они превращаются в отпечаток, который оказывается гораздо устойчивее, чем кажется.
И самое неприятное - этот отпечаток можно получить без cookies, без авторизации и даже без твоего явного согласия. Ты можешь открыть сайт впервые, но для системы ты уже «кто-то знакомый».
Когда я начал разбираться в теме глубже, оказалось, что классические методы вроде Canvas или WebGL - это лишь вершина айсберга. Под ними скрывается целый слой менее очевидных техник: тайминговые атаки, сетевые отпечатки, поведенческие модели и даже попытки идентификации на уровне конкретного железа.
В этой статье я разберу, какие данные реально собирает браузер, как из них строится цифровой отпечаток и почему простые меры вроде VPN не дают той анонимности, на которую многие рассчитывают.
Привет, Хабр.
Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.
В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?
Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.
Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.
Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.
В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.
Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.
«Дуров, верни стену» – мем старый, но точный. ВКонтакте начала 2010-х была, при всех своих недостатках, одним из последних мест в рунете с по-настоящему живой лентой. Не алгоритмической, не персонализированной до тошноты – просто всё подряд от всех, на кого подписан. Новости соседствовали с мемами, мемы – с чьей-то репостнутой статьёй про квантовую физику, которую ты никогда не дочитаешь, но пролистаешь с удовольствием. Была случайность, была живость, был сам факт того, что ты не знаешь, что увидишь следующим.
Потом ВК превратился в то, во что превращается каждая платформа – в алгоритмический прямоугольник, оптимизированный под время на сайте. Мы переехали в Telegram. Telegram честнее: хронологический порядок, никакого умного ранжирования, читаешь то, на что подписался. Но одна вещь так и не появилась – единая лента. В ВК у тебя была стена, куда всё стекалось само. В Telegram двадцать каналов – это двадцать отдельных мест, которые надо обходить руками каждый день.
Папки? Пробовал. Папки – это шкаф. Они раскладывают каналы по полочкам, но за каждой полкой всё равно надо открывать каждый ящик отдельно. Единого потока нет.
Ботов-агрегаторов в маркете штук пять – все сломаны по одной и той же причине: Bot API физически не видит каналы, в которых бот не является администратором. То есть публичный новостной канал с миллионом подписчиков – недоступен. Бот читает только то, куда его добавили руками, а никто не добавляет чужих ботов в админы своих каналов. Логично, но бесполезно.
В какой-то момент я окончательно устал и собрал своё.
Обзор на браузерные API, которые стали Widely available в апреле 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.
Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем.
2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.
Вайбкод это круто, пока не открываешь первый отчёт сканера безопасности и не видишь 234 проблемы. В статье разберём, как выстроить пайплайн вокруг LLM-проекта: подключить SAST-инструменты, настроить Quality Gate как блокировщик деплоя и использовать модель для исправлений — не вместо инструментов, а поверх них. Покажу на реальном проекте с реальными цифрами. Будет полезно тем, кто активно использует LLM для написания кода, и специалистам в области appsec/devsecops.
Часть 1 — контекст, данные из отчёта DryRun Security и немного теории про DevSecOps.
Часть 2 — подключаем SonarCloud, настраиваем Quality Gate, интегрируем в CI/CD.
Часть 3 — первый скан реального проекта: 234 проблемы, как их разбирать и исправлять через Claude 4.6.
Часть 4 — добавляем Semgrep, смотрим, где инструменты расходятся и где ломается подход.
С кэшированием в Next.js обычно случается одна и та же история. API уже отдаёт новые данные, страница открывается заново, а на экране всё ещё старая версия. После этого в код быстро добавляют cache: "no-store", данные начинают запрашиваться на каждый заход, и через пару минут появляется уже другой вопрос - зачем тогда вообще нужен встроенный механизм кэширования.
Проблема в том, что кэширование обычно звучит как одно явление, а на практике в App Router похожие ощущения могут давать разные уровни поведения. Навигация назад и вперёд может переиспользовать клиентский кэш маршрута, сам маршрут может рендериться по-разному, а серверный fetch в Next.js имеет собственные стратегии кэширования и перевалидации. В актуальной документации это уже разделено на новый режим с Cache Components и на прежнюю модель без них. В этой статье речь именно о привычной модели App Router без Cache Components, где поведение обычно задаётся через fetch, cache, next.revalidate и route segment config. (Next.js)
Полезнее всего разбирать такую тему не с теории, а с наблюдения. Не с вопроса как устроены все слои кэша в Next.js, а с вопроса почему на одном и том же маршруте иногда обновляется рендер страницы, а иногда обновляются данные, и это не всегда одно и то же.
Для примеров ниже используется проект Goods Finder и внешний API DummyJSON. Идея - сначала добавить на страницу штамп серверного рендера, потом отдельно показать момент получения данных, а уже после этого сравнить force-cache, no-store и revalidate.
Если вы в последнее время пытались прикрутить к своему любимому LLM‑агенту возможность самостоятельно гулять по интернету, дебажить веб‑приложения, и даже верстать, вы наверняка столкнулись с суровой реальностью. Оказывается, засунуть современный веб в контекстное окно нейросети — очень «дорогая» задача.
Обычно в таких случаях не глядя берут проверенные инструменты вроде Puppeteer или Playwright, которые обернуты в те самые три буквы MCP. Но ребята из Vercel недавно выкатили свою альтернативу — agent‑browser (cli‑утилиту, написанную на связке Rust и, некогда Node, но об этом позже). Зачем понадобился еще один велосипед для автоматизации, если у нас уже есть стандарты индустрии? Давайте разбираться.
За полгода я сделал мобильное приложение, получил 2000 установок и… 8 платных подписок по $6. Причем одна из подписок — моя.
Эта часть будет практической, если помните я решил углубиться в React и Flask. Поэтому при помощи ИИ начинаю. Нет, ИИ не будет делать за меня весь проект, он будет выполнять функцию наставника. Ну и иногда чернорабочего (как, например, собрать файл SQL для инициирования БД) для ускорения ручного труда.
System Prompt учит модель что говорить, Skills — как проверить сказанное, MCP Tools — как сделать это в реальном мире. Разбираем трёхуровневую архитектуру на примере бота техподдержки с валидацией ссылок.
Привет, Хабр.
В сервисном бизнесе есть простой, но обременительный процесс — рассылать уведомления о записях на услуги, готовых заказах и предстоящих визитах. Уведомления нужны салону красоты, автосервису, фитнес-студии, клинике и кому только не.
Пока записей мало, рассылать можно вручную. Когда больше — информация теряется или дублируется, не видно, отправлено ли сообщение и что клиент ответил.
Я Леонид Тараскин, руководитель портфеля продуктов в МТС Exolve. В этом гайде на Python расскажу, как собрать из связки МТС Exolve и MWS Tables легкую CRM с исходящими и входящими СМС-уведомлениями.
Я часто замечаю, насколько некоторые разработчики халатно относятся к вопросам безопасности своих приложений. И начинают задумываться о методах защиты только тогда, когда уже приходится переписывать большую часть приложения. Сегодня мы пройдемся по классическим и не только методам атаки, посмотрим, где компилятор бессилен, и построим современную защиту, опираясь на лучшие практики и конкретные примеры кода.
Статья о том, как решить проблему «забывчивости» LLM между AI-сессиями разработки. Рассматривается причина деградации контекста и предлагается практический подход с использованием ai_readme файлов и агентских хуков, которые принудительно возвращают модель к важным инструкциям. Материал ориентирован на опытных промт-инженеров и показывает, как повысить стабильность и качество генерации кода в реальных больших проектах и при больших контекстных окнах.
Хабр, привет!
Я во фронтенде настолько давно, что учился верстать по текстовым туториалам. В начале десятых годов я и все мои знакомые фронтендеры обязательно были подписаны на рассылки, в которых авторы делились креативными штуками.
По моим ощущениям, сейчас их стало меньше. Все ушли в YouTube, а теперь в ChatGPT. Но мне этот формат не подходит, поэтому я пришёл сюда, к вам.
В прошлом году я создал коллекцию лоадеров. В основе анимации — базовые геометрические фигуры. Я их двигаю, преобразую из одной формы в другую и всё такое.
В этой статье я хочу рассказать весь процесс создания, начиная с самых базовых моментов. Сразу предупреждаю, что в этой статье не будет «живых» вставок. Все эффекты смотрите в моей демонстрации на CodePen.
Давайте посмотрим, что я вам подготовил.
Помните момент, когда сервис работал нормально, но после рассылки, рекламной кампании или наплыва пользователей начал тормозить?
В такие секунды и выясняется, что без нагрузочного тестирования команда на самом деле не знает, где у системы потолок, как проседает производительность и в какой точке критично растёт время отклика. Хорошо настроенное нагрузочное тестирование на Python помогает опираться на цифры: сколько запросов выдерживает API, как ведут себя ключевые бизнес‑сценарии и когда инфраструктура начинает деградировать.
