Выглядит это как то так

Настроят ClawdBot и любые AI интеграции, недорого. Без макак - я никак.

Отладка кода в наше время всё больше напоминает мне слот-машину.

Вылез exception? Депозит в чат → спин.
Исправь ❌❌✅
Исправь ❌❌✅
Исправь ✅❌✅
Спин. Спин. Спин.
И вот оно!
✅✅✅
ВОТ ЭТО ЗАНОС!🤑🤑🤑
Тесты проходят, проект запустился!

Адреналин, сердце стучит, эйфория.

Это точно еще можно назвать "разработкой"? 🤔

Наконец-то распробовал 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, который в итоге затащили вообще везде и всюду.

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

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

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