Kurgan-Telecom Ru | Информационные технологии

Этот месяц оказался достаточно насыщенным в плане новых моделей. Пока одни разработчики только анонсировали обновления, другие уже успели выкатить полноценные релизы. В итоге февраль подарил нам сразу несколько громких новинок: Gemini 3.1 Pro, ChatGPT 5.3 Codex, Nano Banana 2, Seedance 2.0 – и, конечно, главных для сегодняшней статьи: Claude Sonnet 4.6 и Claude Opus 4.6.

Обе модели от Anthropic я уже успел поюзать достаточно, чтобы составить о них какое-то мнение. Именно поэтому решил не держать тесты при себе, а оформить их в сравнение – как это уже было в прошлой статье про ChatGPT 5.2 Pro и Gemini 3.1 Pro.

Сразу скажу: никакого официального крупного бенчмарка здесь не будет. Это сугубо личный эксперимент, затеянный из собственного любопытства. Тем не менее, если вы сами выбираете между этими двумя моделями или просто следите за развитием ИИ, возможно, статья поможет вам подметить что-то полезное: плюсы, минусы, неочевидные нюансы каждой из версий.

Что ж, принимайте стратегически удобное положение – я приступаю.

OpenAI 5 месяцев строили продукт без единой строчки ручного кода — миллион строк, 1500 PR, 7 инженеров. Разбираю их подход «harness engineering» и что из этого можно применить уже сейчас: как организовать AGENTS.md, почему скучные технологии побеждают, и зачем нужна архитектура с первого дня.

Как одна журнальная статья, написанная 70 лет назад, поменяла всю инвестиционную индустрию и принесла ее автору Нобелевскую премию.

В одном из последних интервью ее автор вспоминал: «Когда люди восторгаются моей Нобелевской премией, я люблю говорить им, что Нобелевская премия не была моей самой большой наградой. Моя самая большая награда была вручена мне в мужском туалете большого отеля в Вашингтоне, округ Колумбия, после ужина, где-то между Рождеством и Новым годом 1990 года»...

Сегодня ядром данной статьи будет MCP — как мост между бекендом‑оберткой с LLM и внешними источниками, но при этом я также затрону смежные темы, чтобы картина была полной и не требовалось дополнительно гуглить.

Я постараюсь не давать устоявшиеся термины в контексте MCP, а также в процессе буду пояснять некоторые «базовые» термины, которые все как бы понимают — но нередко нет, чтобы мы все улавливали один и тот же контекст статьи.

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

С тех пор развитие гаджетов шагнуло очень далеко и я прогрессирую в их использовании. Хочу рассказать свой опыт не с точки зрения всех устройств, а про наверное самый популярный - whoop.

У меня сейчас браслет whoop peak. В России его можно без проблем приобрести за ~ 30к рублей, что будет в себя включать годовую подписку. Годовая подписка на мой гаджет стоит 239$ в год. Есть еще тариф за 359$, который включает в себя ЭКГ, измерение давления и прочие фишки для людей с рисками по сердцу, но я пока решил ограничиться версией без этого. Подписка у whoop достаточно дорогая, многие смартчасы предоставляют много данных бесплатно, а ближайший похожий девайс кольцо Oura стоит 7$ в месяц.
Аксессуары для whoop тоже достаточно дорогие, ремешки в США стоят порядка 50$, в Москве 10-12к руб. Есть китайские, но мне не понравилось их качество.

У меня никогда не было состояния «идей нет». Идей — хоть отбавляй. Проблема всегда была в другом: когда я сажусь и начинаю специально их придумывать, мозг часто выдаёт ровно то, что от него ожидают: безопасное, предсказуемое, «правильное». А вот когда я задаю себе вопрос, формулирую задачу и отпускаю, — идеи становятся заметно сильнее: неожиданнее, сложнее, ближе к тому, что цепляет игрока.

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

Если вы считаете, что Vampire: The Masquerade - Bloodlines 2 - плохая игра, умершая в тени величия своего прародителя, - вы ошибаетесь. Сегодня я покажу вам другую сторону и честно обрисую своё собственное видение. Разбираю каждую часть по основным аспектам жанра и игр.

С 1960-х годов в архивы по всему миру начали поступать на хранение цифровые документы. Изначально небольшая, их доля среди собраний возрастала каждое десятилетие. Цифровые фонды при этом бросают вызов одной из главных функций архива: сохранять поступившее в неизменном виде. Неизменяемость для цифрового документа означает смерть, ведь уже через несколько десятков лет может не найтись ни одной машины, которая способна его открыть.

О том, как архивисты и программисты десятилетиями искали выход из этой ситуации, и как цифра меняет основы архивного дела рассказывает германский архивист Кристиан Кайтель. С его разрешения (и благословения издательства) мы публикуем отрывок из его книги «Двенадцать путей в архив. Контуры открытого и прикладного архивоведения».

Keitel C. Zwölf Wege ins Archiv. Umrisse einer offenen und praktischen Archivwissenschaft. Stuttgart: Franz-Steiner-Verlag, 2018. S. 188-202. Перевел Никита Ломакин (телеграм-канал Архивный гик), редактировала Анастасия Тарасова.

Представим ситуацию.

Маркетолог работает в крупной компании с собственной A/B-платформой. Каждый квартал он должен запускать несколько новых маркетинговых кампаний, и подтверждать их эффективность с помощью экспериментов. Ресурса аналитика всегда не хватает на подобные задачи. А A/B-платформа позиционируются как инструмент, доступный в том числе маркетологам и проектным менеджерам. В итоге, наш герой решает запустить эксперимент самостоятельно.

Гипотеза. «Новый лендинг увеличивает среднюю выручку на пользователя (ARPU) в выбранном сегменте».

Спустя несколько недель маркетолог открывает AB-платформу, чтобы подвести итоги эксперимента. Видит, что пользователи распределены по группам примерно равное: 9 936 в тесте и 10 068 в контроле. Результат радует глаз: effect = 18.28%. "Какой эффект! Вот только чувствительности для "прокраса" немного не хватило", - думает он, - "глядя на p-value = 0.1179".

Но можно ли принимать решения на основе этих данных? Давайте разберемся, проведя анализ вероятных искажений.

ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится.

Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача.

Мне это надоело и я полез разбираться.

Cегодня редко встретишь разработчика, который хоть раз бы не слышал о Rust. После долгого хайпа и зародившегося мема RIIR (rewrite it in Rust — перепиши это на Rust) ажиотаж вокруг языка как будто бы поутих. Но оказалось, все и вправду по‑тихому переписывается на Rust (если мой дебют не утонет в минусах, постараюсь написать статью‑исследование на тему, где уже Rust надежно поселился в системе).

Первое, что меня впечатлило — это статья, что вся инфраструктура Cursor написана на Rust в целях экстремальной производительности, и язык с этой задачей, как видно, прекрасно справляется. Второе, что и сподвигло не только читать о Rust, но и начать на нем писать, — это, конечно же, дефицит комлектующих. «640 КБ на самом деле хватит всем» и интерес пал на братьев наших меньших — микроконтроллеров. Вот где действительно можно прочувствовать всю необходимость оптимизации.

Конечно, знакомство с Rust, как и у всех, началось с классики — Rust book для новичков и Embedded Rust для желающих окунуться в разработку встроенных систем. В Rust Book новичкам предлагается написать простую программу Guessing Game — приложение, которое загадывает число, а «игрок» должен попытаться его угадать.

Но просто читать не так интересно как набивать свои собственные шишки, поэтому, вооружившись книгами, документацией, все еще живым StackOverflow и Gemini в качестве ментора, я решила объединить эти два мира и сделать Guessing Game на STM32.

Далее хочу предложить небольшой гайд (или просто объяснение кода) из того, в чем удалось разобраться.

Трудно с уверенностью сказать, какие игры или жанры были самыми популярными в первые годы существования компьютерных игр. Многие игры продавались напрямую по почте или через небольшие магазины, у которых был один владелец, и ни одна организация, занимавшаяся торговлей программным обеспечением, не собирала полную статистику продаж. В 1980 году журнал Softalk начал публиковать список тридцати самых продаваемых программ для Apple II, составленный на основе опросов розничных продавцов. Он не предоставлял (и не мог предоставить) абсолютные цифры продаж, однако, хотя первое место занимал VisiCalc, двадцать две позиции из этого списка были играми. Большинство из них были CRPG, приключенческими и аркадными играми (включая Automated Simulations’ Temple of Apshai, Sierra’s Mystery House и лабиринтную игру Head On). Microsoft Flight Simulator и шахматная игра Sargon II заняли второе и четвёртое места, а военные игры Computer Bismarck и Computer Ambush от Strategic Simulations, Inc. (SSI) оказались в двадцатке.

Продолжаю серию статей про вайб кодинг для чайников (это я). Сегодня про главную боль: почему всё, что генерирует ИИ в плане веб-дизайна, выглядит одинаково пластиково, и что с этим делать на практике.

Хотелось бы свалить на конкретную модель и сказать - "надо просто выбрать вот эту и всё будет тип топ". Но на самом деле - это проблема подхода: по умолчанию ИИ пишет и оптимизирует код подходом "работает и не ломается", а не "выглядит как лучшие примеры с Awwwards". У него нет контекста вашего бренда, нет визуального фидбека на результат, нет источника вдохновения. Он берёт самый частотный паттерн из обучающей выборки, и вы получаете среднее арифметическое всех шаблонов интернета (стоит признать - иногда и так нормально). Давайте это починим в этой статье.

Синхронизация атрибутов элемента с DOM-свойствами

Очевидно, что нашему компоненту потребуются атрибуты, через которые пользователь сможет контролировать его поведение. Наш компонент должен вести себя как стандартный элемент ввода типа «input», поэтому обязательно должен поддерживать такие атрибуты как disabled и required – и это самый минимум. Поэтому важно разобраться (ну или вспомнить) что такое «content vs IDL attributes», и как с этим работать.

Документация по веб-компонентам мало говорит об атрибутах, разве что рекомендует использовать attributeChangedCallback() для наблюдения за ними, но этого недостаточно. Хотя это полезное API, нам оно не подходит, потому что оно уведомляет нас о уже совершенном действии (изменении атрибута), а нам нужно контролировать этот процесс, то есть – синхронизировать атрибуты и свойства с нормализацией значений.

Так как наш компонент наследует базовый класс HTMLElement, а в нем уже реализовано большое количество разных методов, то мы можем переопределить некоторые из них чтобы получить нужный нам результат. Для начала определим наши свойства в виде пар get/set и значения в приватном поле:

Ну что ж, вот и вышла долгожданная Resident Evil: Requiem. Я уже успел пройти её, впереди теперь ждёт самый хардовый уровень сложности. Да, я пройду её дважды, и да - оно того стоит. 

В соц. сетях игру уже успели окрестить чуть ли не «лучшей в серии» и она вполне способна побороться за такое звание. Почему и чем способна удивить новая часть Резика я и хотел бы сегодня рассказать, плюс очень хотел бы обсудить крышесносные сюжетные моменты, НО сегодня эта статья — своеобразный «save room», где можно не опасаться спойлеров, ознакомиться с деталями геймплея и узнать — сдержали ли Capcom свои обещания.

Краткий итог нашего изучения рынка и создания собственного бота (почему это так - читайте ниже):

Промпт-бот (500 ₽ фриланс + 50 000 ₽/месяц API):
Используйте, если нужно простое FAQ-покрытие, вся база знаний умещается в короткий промпт, нет регуляторного риска и вы понимаете, что принимаете риск галлюцинаций и нарушений ограничений. Хорошо для демонстрации возможностей. Не подходит для финансовых услуг, медицины, юридических вопросов или любой области, где неверный ответ бота имеет последствия.

SaaS-платформа (3 000–100 000+ ₽/месяц):
Используйте, если главным образом нужно FAQ-отклонение и маршрутизация обращений, каталог продуктов стабилен и прост, есть команда поддержки, которая хочет единый inbox, и вы хотите запуститься за несколько дней. Aimylogic и BotHelp достаточно хороши для своего предназначения. Российские платформы решают вопрос 152-ФЗ лучше западных аналогов.

Open-source-фреймворк (Rasa/Botpress, $0 ПО + инфра + программисты):
Rasa даёт полный контроль с локальным NLU и управлением диалогом. Требует Python-инженера и реальных обучающих данных. Корпоративное лицензирование начинается от $35 000/год. Подходит для ML-тяжёлых сценариев, где нужен полный контроль. Требует постоянной поддержки, которую SaaS берёт на себя.

Кастомный гибрид (инвестиции в код + ~5 000 ₽/месяц API):
Используйте, если нужны управляемые многошаговые квалификационные потоки, данные о продуктах синхронизированы с существующей системой, есть требования к локализации данных или соответствию 152-ФЗ, нестандартная интеграция с каналами или предсказуемость затрат на долгий срок. Не проект выходного дня, но при масштабировании экономика очевидна. По данным рынка, полная разработка «под ключ» в России стоит 70 000–1 000 000 ₽ единоразово (медиана 227 000 ₽ по исследованию Aimylogic).

Я — довольно нетипичный пользователь хабра. Не играю по правилам, не подчиняюсь мнению большинства, не считаю программистов — умными людьми априори, никогда не ставлю минусы, потому что охранка и вертухайство меня никогда не привлекали. Меня предупреждали, банили, мои тексты в песочницу (тут я играю по правилам, ударили исподтишка — встал, отряхнулся, снова попытался войти через парадный вход) — заворачивали со смешной формулировкой «кажется, это написала LLM». Третий текст я справился пропихнуть в песочницу (у местных вахтеров закончились аргументы, наверное), и спустя месяц с лишним — нашелся человек, которому он понравился. Спасибо, @oeditus, надеюсь, я не подставлю вас этим текстом.

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

Вводные: у меня зелёная карма, как говорят в недружественных странах — always has been, положительные рейтинги у всех тестов (статьями пусть их называют недотыкомки с напыщенными щеками), ничтожно мало заминусованных комментариев. Я не скрываю свои гитхаб и прочие интернет-аватары. Я не ожидал, что найдутся люди, которые решат (безуспешно, разумеется) тратить своё время, чтобы нагадить мне повсеместно. (Спойлер — они нашлись, и модераторы соответствующих форумов даже помогли мне их вычислить.)

Я пишу технические тексты, показываю пути решения задач, которые показались мне нетривиальными, рассказываю о собственных библиотеках в OSS (не прошедший модерацию в песочнице текст — был как раз таким), но я получил предсказуемый отлуп:

Вообще, я большой любитель экзотических гаджетов и разной диковинки. Порой мониторю барахолки в поисках чего-то такого, что не продавалось в условной «Евросети», а если гаджет попадается нерабочий, то стараюсь его восстановить. Особый кайф мне приносит ремонт материнских плат — объём дофамина от чувства того, что ты только что восстановил устройство, на котором поставили крест более 10 лет назад, просто невероятный!

Недавно мне в руки попал уникальный смартфон-игровая консоль JXD S5800, который при внешней целостности не подавал никаких признаков жизни. После короткой диагностики виновник нашелся быстро. В этой статье расскажу не только о ремонте и о том, причем здесь Samsung, но и детально разберу аппаратную платформу типичного смартфона тех лет. Если интересно — жду под катом.

Статья для PM и тимлидов, которые работают в арт‑аутсорсе или других креативных командах с высокой вариативностью задач.

Я разбираю систему из четырёх метрик — estimation accuracy, task complexity, variability и volatility — которая помогает видеть устойчивость проекта, прогнозировать перегрев и принимать управленческие решения без усиления контроля над командой.

Внутри: как считать каждую метрику, как читать их вместе, как внедрить без потери доверия художников и тимлидов, и какие ошибки я совершила на старте.