Кисель в АйТи | AI и технологии

Короче, я долго думал, писать об этом или нет. Решил, что да. Вы заслуживаете узнать об этом из первых уст. Последние три месяца я проходил собеседования в Anthropic. Пять раундов. System design на салфетке в зуме в 3 часа ночи. Финальный созвон лично с Дарио Амодеи, где он спросил, как я отношусь к AGI. Оффер пришёл вчера вечером. Должность — Head of Applied Research. Пакет такой, что у меня от воодушевления до сих пор трясутся руки. Только есть одно условие: полный информационный карантин. Никаких блогов про технологии и AI. Вообще. «Ты можешь писать про котиков и рецепты, но не про AI» — дословная цитата HR. Я посмотрел на оффер. Посмотрел на подписчиков. На каждый пост в канале. На реакции. И снова на оффер. И написал: «Thank you for the opportunity, but I have to decline.» Я остаюсь с вами. Просто подпишитесь и поставьте лайк, наконец-то.

Нашёл просто мега полезный сервис. Называется GitHub. Можно хранить код ПРЯМО В ИНТЕРНЕТЕ. Не на флешке, не в архиве на рабочем столе, не в письме самому себе - а на сервере. И он ещё и версии сохраняет. Я удалил файл - а он помнит. Я сломал всё - а там кнопка "откатить". Пять лет жизни среди папок "project_final_v3_ПОСЛЕДНИЙ_точно" - и всё это время решение было на расстоянии одного сайта. Будущее наступило! Ура! 🥹

🥷 axios взломали. Да, тот самый axios. Сегодня ночью кто-то угнал npm-аккаунт главного мейнтейнера axios и залил две отравленные версии — 1.14.1 и 0.30.4. Схема элегантная: в зависимости тихо подсунули левый пакет plain-crypto-js. При npm install он ставит RAT - троян удалённого доступа. Под мак, винду и линукс. После установки подчищает за собой следы - в node_modules всё выглядит нормально. Троян стучится на C2-сервер каждую минуту. Ждёт команд. Может запускать шелл, лазить по файлам, тащить данные. Полный контроль над машиной. Окно было ~3 часа. Но у axios 100 миллионов загрузок в неделю. Так что потенциально зараженных машин очень много. Если не повезло - лучше ротируйте всё: SSH-ключи, токены, API-ключи. Откатитесь на 1.14.0 или 0.30.3. Пересоберите окружение с нуля. А главный урок всё тот же: npm-токен мейнтейнера утёк — и весь CI/CD, код-ревью, подписанные коммиты оказались бесполезны. Атакующий просто зашёл через npm CLI мимо всего. Такие дела.

Видимо в этом году нас удивит не только Google. Из-за ошибки в настройке CMS Anthropic слила 3000 внутренних документов в открытый доступ. И там было кое-что интересное про их новую модель. Она засветилась там под именем «Claude Mythos». Так же появился новый таер выше Opus - «Capybara». Anthropic по итогу подтвердил существование модели, назвав её «step change» в возможностях и «самой мощной из когда-либо созданных ими». По данным утёкшего черновика, по сравнению с Claude Opus 4.6 новая модель показывает значительно более высокие результаты в программировании, академическом рассуждении и кибербезопасности. При этом в черновике прямо говорится, что модель «очень дорога в обслуживании» и компания работает над повышением эффективности перед любым массовым релизом. В утёкшем же черновике Anthropic заявляет, что модель «создаёт беспрецедентные риски кибербезопасности» и способна находить и эксплуатировать уязвимости значительно быстрее защитников. Как думаете, уже пора начинать волноваться? 🙊

Нежданно-негаданно. Вот так вот вдруг Google выкатил TurboQuant — и это, возможно, главная новость с начала года в ML. Освежим в памяти: когда LLM ведёт с тобой длинный диалог, она хранит в памяти GPU «заметки» обо всём, что уже обсудили. Это называется KV-кэш, и именно он сжирает всю память при длинных промптах. TurboQuant сжимает этот кэш в 6 раз. Ускоряет вычисления до 8x. Без потери качества. Без дообучения модели. Просто подключил - и работает. Открытого кода от Google пока нет, но статья уже принята на ICLR 2026. Сейчас на потребительской GPU с 24 ГБ VRAM можно крутить 7B-модель, но с контекстом 4-8k. Если KV-кэш ужимается в 6 раз, тот же ноутбук тянет 32-64k контекста. Для локальных ассистентов и всего, где важна приватность - это качественный скачок, который открывает много новых дорог новым инструментам. Миллион токенов контекста перестанут быть роскошью. Возможно мы увидим модели с контекстом на порядки выше. Что ж, посмотрим что нас ждёт дальше.

Зелёные тесты ≠ хорошие тесты Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты. Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не "поймает ли тест баг в этой строке", не "проверяет ли он правильность результата" - просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль. Мутационное тестирование - это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на -, True на False. Каждая такая поломка - мутант. Если после мутации все тесты по-прежнему зелёные - значит они ничего не проверяют. Покрытие есть, защиты нет. Почему это важно именно сейчас? Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что-то - и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай - тест всё равно зелёный. Потому что он проверяет не правильность, а наличие. Мутационное тестирование - единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% - плохо. 90%+ - тесты реально что-то защищают. Кое-какие инструменты для такого тестирования уже есть: mutmut и cosmic-ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест-рана. Но запускать его не нужно на каждый коммит - достаточно на PR в критические модули. Но есть нюансы. А где их нет, правда? Первый: мутации рандомные. Замена > на >= - это не баг, который кто-то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой - формально проверка, по факту мимо. Второй - ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% - и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод - 40 тестов красные. Поменял порядок полей в ответе - ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию. Это реально ловушка. Слишком гонишься за mutation score - получаешь хрупкие тесты. Не гонишься - получаешь видимость тестирования. Перемены - впереди! И вот тут становится по-настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case - ровно так, как ошибается человек. Или другая нейронка. Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не "выжили ли тесты после рандомной поломки", а "выжили ли тесты после правдоподобной ошибки". Парадокс в том, что мутационное тестирование было нишевым инструментом, пока тесты писали люди. Когда тесты пишет нейронка - идея становится обязательной. Правда инструменты пока не успели дозреть. Ждём, когда мутанты станут умнее.

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

Есть тут у нас пользователи Клод Кода? Расскажите, какие используете скилы. Они недавно даже плагин для их создания/тестирования выкатили. Но... Я так и не придумал ни одного полезного юзкейса.

Сегодня участвовал в олимпиаде по программированию, но не простой. Это была битва на llm-ках. Что я могу сказать? Давно я с таким интересом не решал задачки. А ведь никто такое не проводит, хотя это самый логичный шаг - хватит запрещать использовать то, что все и так будут использовать Всем станет от этого только легче и интереснее. Главное - подобрать задачки, которые не по зубам современным моделям. Из 6 задач было две таких - больше часа пришлось бороться за каждый процент производительности, чтобы набрать максимум баллов. Можешь жонглировать языками и нейронками, главное - результат. Естественно кажется, что Opus 4.6 или Gemini 3.1 Pro быстро всех нагнут. По факту они практически бесполезны. High effort thinking играет с ними злую шутку. Оба уходят думать на 20 минут, а потом отваливаются по таймауту/лимиту токенов. Самый главный инсайт - в таких вещах ооочень сильно решает итеративный подход. Чем быстрее ты получишь первый результат, тем быстрее сможешь итеративно довести его до идеала. Пока Опус думал - Gemini Flash уже успела погуглить все самые эффективные стратегии, прогнать их на тестах и выбрать лучшее. Кое кто спустя 2 часа смог выбить 100 баллов в самых сложных задачках (всего два-три человека из пятидесяти). Видимо они догадались использовать более легковесные модели чуть раньше меня. Что я могу сказать? Опыт крайне интересный. Классическая зубрежка алгоритмов отходит на второй план всё сильнее и сильнее. А новые подходы позволяют добиться такой эффективности, на достижение которой раньше бы просто не хватило времени.

⚡️⚡️⚡️РАЗРАБОТЧИКИ ВСЁ ⚡️⚡️⚡️ Ладно, шучу. Больше никакого кликбейта (сегодня). Сейчас в очередной раз увидел новость от Антропика, что разработчики доживают свой последний год. И снова эти "эксперты" путают карту с местностью. Но у нас же с вами есть голова на плечах? Так что давайте сами и подумаем. Типичный менеджер/аналитик - человек очень далёкий от кода и архитектуры. Да, двигает задачки, общается с бизнесом, делает красивые таблички, НО В КОДЕ НИЧЕРТА НЕ ПОНИМАЕТ. И не поймёт, даже если попросит ЧатГПТ объяснить. Почему? Да потому что даже если человек знает синтаксис - у него нет самого главного. Нужное мышление нарабатывается годами. Разработка это вообще не про "писать код", вот так открытие! По какой-то необъяснимой для меня причине каждый раз упускается из вида самое главное. Рабочее приложение != "кнопочки жмутся, всё работает". Это верхушка айсберга, которую видно. Всё на самом деле сильно-сильно глубже. Все эти красивые сервисы, где ты натыкал в графе приложение и оно задеплоилось не применимы ни для одной серьезной компании. Это хорошо работает для стартапа или MVP, у которого трафик 1,5 колеки. И естественно, у человека "не из разработки" нет даже примерного понимания того, как это устроено изнутри. Чёрный ящик. Он не объяснит, почему выбрал тот или иной подход. Не заметит, что он был ошибочным. И это на проектах, в которых дай бог 2-3 сервиса, БД и nginx. Может ли такой человек довести проект до зрелого, стабильного состояния, который сможет развиваться годами? Сомневаюсь. Даже если допустить, что какой-нибудь Claude 5.7 будет в 10 раз умнее нынешнего - проблема не в этом. Хороший инженер с хорошим инструментом может написать в 10 раз больше хорошего кода. Плохой инженер - напишет в 10 раз больше плохого кода. Пока что я не видел ни одного кейса, который мог бы опровергнуть это утверждение. Ты должен понимать, как работает твоё приложение и почему оно так работает. Это еще один скилл, который каждый разработчик приобретает годами. Это та самая "карта проекта" в голове, которая помогает тебе быстро и эффективно решать задачи. И это понимание спасает от многих проблем и ошибок, которые с ростом проекта становится нереально дорого исправлять. Даже с нейронками. Еще свежи в памяти падения Cloudflare, AWS и десятка других сервисов. Почему? Потому что инженеры дали слишком много прав агенту, либо невнимательно проверили сгенерированный конфиг или код. НАСТОЯЩИЕ ИНЖЕНЕРЫ, КОТОРЫЕ ПОНИМАЛИ, ЧТО ДЕЛАЮТ. Лицо менеджера-вайбкодера, когда у него упал целый датацентр представили?) Сможет ли медсестра поставить диагноз с chatgpt точнее, чем опытный врач, который использует тот же инструмент? Нет. Получается, что сам "инструмент" - не решающий фактор. Почему все сравнивают "вот я с гпт такооое могу, увольняйте всех бэкендеров"? И что, я с тем же ГПТ могу больше и быстрее. На самом деле именно разработчики выигрывают больше всех с развитием ИИ. Сделать нормальное приложение сложнее, чем оформить табличку в аналитике. И уж явно сложнее 99% задач, которые выполняют менеджеры. Думаю Клод с этим справится на ура. Всё потихоньку движется к концепции software-инженера, который сам отвечает за аналитику, сроки выполнения и разработку. Ну и конечно же акцент больше сместится на проектирование архитектуры. Мы просто будем тратить меньше времени на код. И этот подход будет в десятки раз эффективнее любого "менеджера-аналитика-вайбкодера". Что думаете?

⚡️⚡️⚡️ВАЙБКОДИНГ ВСЁ ⚡️⚡️⚡️ Там ночью по датацентру в ОАЭ прилетело, Claude лежит уже больше 7 часов 😐

Вышло любопытное исследование SkillsBench. Они протестировали кучу LLM-агентов (от Claude 4.5 до Gemini 3 и GPT-5.2) на то, как они решают задачи с использованием Skills и без них. Главный инсайт: грамотно написанные скилы могут помочь даже младшим моделям обойти старших. Младшие и дешевые модели (например, быстрая Gemini Flash или Haiku) с правильной «обвязкой» в виде Skills обходят тяжеловесов (Pro/Opus), которые пытаются решить задачу без скилов. Прирост успешных решений с готовыми скиллами в среднем составил +16,2%. Но есть нюансы. 1. Самогенерация не работает. Как только модели предлагают сгенерировать Skills для себя, их результативность падает. 2. Больше — не значит лучше. Оптимальный объем для агента — 2–3 скилла (дает прирост +18,6%). Если напихать 4 и более, эффективность резко падает. Если закинуть агенту полную и подробную документацию, он в ней буквально тонет, и результат уходит в минус (–2,9%). Ссылочки: https://www.skillsbench.ai/ https://arxiv.org/pdf/2602.12670

Совершенно случайно вывел новый термин. КуКлод-разработчик - человек, который смотрит, как Клод пишет код в его проекте.

Да, чувствую себя именно так 😂

Для меня всегда было загадкой, почему core-команда Python так и не родила нормальный инструмент, чтобы этим Python пользоваться. Это чуть ли не самое главное в языке. Входная точка, через которую проходит каждый разработчик десятки тысяч раз. Тем временем они уже 10 лет везут асинхронную установку пакетов в pip, пока комьюнити городит костыли из костылей с окружениями. Мы уже видели: - virtualenv - pip - tox - venv - flit - pipenv - poetry - pdm - hatch - rye И кажется это еще не конец. У кого нибудь есть этому объяснение?

Наконец-то распробовал uv. Тот самый "убийца pip" на Расте от команды Astral. Удобненько, ооочень шустро работает, с зависимостями не косячит. Всё наше добро вписываем в pyproject.toml, делаем uv sync для установки, 5 секунд ждём и готово! Естественно, появится lock-файл, в котором будут зафиксированы все зависимости. Очень понравилось, как устроены "группы зависимостей". В одном файле prod/dev/test зависимости, только разнесённые по группам. На фоне пипа с миллионом файлов requirements.txt/requirements.test.txt и т.д - очень вкусно. Но и это не всё. Хотя избавиться от тормознутого pip'а это уже удовольствие. Есть еще кое-что: он умеет скачивать и устанавливать нужные версии Python. И переключаться между ними можно одной простой командой. ## Шпаргалка по командам - uv init — инициализировать новый проект с pyproject.toml - uv add <package> — добавить пакет в зависимости и синхронизировать окружение - uv remove <package> — удалить пакет из проекта - uv sync — синхронизировать venv с текущим lock-файлом - uv sync --all-groups — синхронизировать все группы зависимостей - uv sync --only-group dev — синхронизировать только зависимости для dev-окружения - uv sync --no-dev — синхронизировать всё, кроме dev-окружения - uv lock — обновить только uv.lock без установки пакетов - uv run <script.py> — запустить скрипт внутри изолированного окружения - uv python install 3.13 — скачать и установить конкретную версию Python в систему - uv python list — посмотреть список всех доступных и установленных версий Python

version = "0.1.0"
dependencies = [
    "fastapi == 0.115.0",
    "sqlalchemy >= 2.0.25",
    "uvicorn[standard] >= 0.27.0",
]

[dependency-groups]
dev = [
    "ruff ~= 0.2.0",
    "pytest >= 8.0.0, < 9.0.0",
]

Еще из плюсов: - Нормальный, человеческий (наконец-то!) мать его кэш! Один раз скачал библиотеку и всё. - Читаемый лок-файл uv.lock. Приемлемо выглядит в диффах. Хочется верить, что инструмент повторит судьбу ruff, который в итоге затащили вообще везде и всюду.

ChatGPT оказывается умеет в стиль желтушных СМИ. Собрал для вас последние актуальные новости 😂

И в догоночку. Как вам концепт первого в мире вайббука? Ничего лишнего 💳

Отладка кода в наше время всё больше напоминает мне слот-машину. Вылез exception? Депозит в чат → спин. Исправь ❌❌✅ Исправь ❌❌✅ Исправь ✅❌✅ Спин. Спин. Спин. И вот оно! ✅✅✅ ВОТ ЭТО ЗАНОС!🤑🤑🤑 Тесты проходят, проект запустился! Адреналин, сердце стучит, эйфория. Это точно еще можно назвать "разработкой"? 🤔