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

Тем временем они уже 10 лет везут асинхронную установку пакетов в pip, пока комьюнити городит костыли из костылей с окружениями.

Мы уже видели:
- virtualenv
- pip
- tox
- venv
- flit
- pipenv
- poetry
- pdm
- hatch
- rye

И кажется это еще не конец. У кого нибудь есть этому объяснение?

Совершенно случайно вывел новый термин.

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

Вышло любопытное исследование 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

⚡️⚡️⚡️ВАЙБКОДИНГ ВСЁ ⚡️⚡️⚡️

Там ночью по датацентру в ОАЭ прилетело, Claude лежит уже больше 7 часов 😐

⚡️⚡️⚡️РАЗРАБОТЧИКИ ВСЁ ⚡️⚡️⚡️

Ладно, шучу. Больше никакого кликбейта (сегодня). Сейчас в очередной раз увидел новость от Антропика, что разработчики доживают свой последний год. И снова эти "эксперты" путают карту с местностью. Но у нас же с вами есть голова на плечах? Так что давайте сами и подумаем.

Типичный менеджер/аналитик - человек очень далёкий от кода и архитектуры. Да, двигает задачки, общается с бизнесом, делает красивые таблички, НО В КОДЕ НИЧЕРТА НЕ ПОНИМАЕТ. И не поймёт, даже если попросит ЧатГПТ объяснить. Почему? Да потому что даже если человек знает синтаксис - у него нет самого главного. Нужное мышление нарабатывается годами. Разработка это вообще не про "писать код", вот так открытие!

По какой-то необъяснимой для меня причине каждый раз упускается из вида самое главное. Рабочее приложение != "кнопочки жмутся, всё работает". Это верхушка айсберга, которую видно. Всё на самом деле сильно-сильно глубже. Все эти красивые сервисы, где ты натыкал в графе приложение и оно задеплоилось не применимы ни для одной серьезной компании. Это хорошо работает для стартапа или MVP, у которого трафик 1,5 колеки. И естественно, у человека "не из разработки" нет даже примерного понимания того, как это устроено изнутри. Чёрный ящик. Он не объяснит, почему выбрал тот или иной подход. Не заметит, что он был ошибочным. И это на проектах, в которых дай бог 2-3 сервиса, БД и nginx. Может ли такой человек довести проект до зрелого, стабильного состояния, который сможет развиваться годами? Сомневаюсь. Даже если допустить, что какой-нибудь Claude 5.7 будет в 10 раз умнее нынешнего - проблема не в этом.

Хороший инженер с хорошим инструментом может написать в 10 раз больше хорошего кода. Плохой инженер - напишет в 10 раз больше плохого кода. Пока что я не видел ни одного кейса, который мог бы опровергнуть это утверждение. Ты должен понимать, как работает твоё приложение и почему оно так работает. Это еще один скилл, который каждый разработчик приобретает годами. Это та самая "карта проекта" в голове, которая помогает тебе быстро и эффективно решать задачи. И это понимание спасает от многих проблем и ошибок, которые с ростом проекта становится нереально дорого исправлять. Даже с нейронками.

Еще свежи в памяти падения Cloudflare, AWS и десятка других сервисов. Почему? Потому что инженеры дали слишком много прав агенту, либо невнимательно проверили сгенерированный конфиг или код. НАСТОЯЩИЕ ИНЖЕНЕРЫ, КОТОРЫЕ ПОНИМАЛИ, ЧТО ДЕЛАЮТ. Лицо менеджера-вайбкодера, когда у него упал целый датацентр представили?) Сможет ли медсестра поставить диагноз с chatgpt точнее, чем опытный врач, который использует тот же инструмент? Нет. Получается, что сам "инструмент" - не решающий фактор. Почему все сравнивают "вот я с гпт такооое могу, увольняйте всех бэкендеров"? И что, я с тем же ГПТ могу больше и быстрее.

На самом деле именно разработчики выигрывают больше всех с развитием ИИ. Сделать нормальное приложение сложнее, чем оформить табличку в аналитике. И уж явно сложнее 99% задач, которые выполняют менеджеры. Думаю Клод с этим справится на ура. Всё потихоньку движется к концепции software-инженера, который сам отвечает за аналитику, сроки выполнения и разработку. Ну и конечно же акцент больше сместится на проектирование архитектуры. Мы просто будем тратить меньше времени на код. И этот подход будет в десятки раз эффективнее любого "менеджера-аналитика-вайбкодера".

Что думаете?

Сегодня участвовал в олимпиаде по программированию, но не простой. Это была битва на llm-ках. Что я могу сказать? Давно я с таким интересом не решал задачки. А ведь никто такое не проводит, хотя это самый логичный шаг - хватит запрещать использовать то, что все и так будут использовать Всем станет от этого только легче и интереснее.

Главное - подобрать задачки, которые не по зубам современным моделям. Из 6 задач было две таких - больше часа пришлось бороться за каждый процент производительности, чтобы набрать максимум баллов. Можешь жонглировать языками и нейронками, главное - результат.

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

Что я могу сказать? Опыт крайне интересный. Классическая зубрежка алгоритмов отходит на второй план всё сильнее и сильнее. А новые подходы позволяют добиться такой эффективности, на достижение которой раньше бы просто не хватило времени.

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

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

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

Зелёные тесты ≠ хорошие тесты

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 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 - ровно так, как ошибается человек. Или другая нейронка.

Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не "выжили ли тесты после рандомной поломки", а "выжили ли тесты после правдоподобной ошибки".

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

Ждём, когда мутанты станут умнее.