Нужна ли умная модель для рутины? Дал четырём моделям пять одинаковых задач и сравнил
На этой неделе на Хабре спорили, нужны ли программисту самые умные модели: «Я перестал пользоваться самыми умными ИИ‑моделями». Автор считает, что для рутины хватает дешёвых, а упирается всё теперь в скорость. Под статьёй почти триста комментариев. Я прочитал, наверное, половину: мнений много, замеров на одинаковых задачах не нашёл ни одного. Стало интересно, сел и проверил на своих.Что мерилВзял пять задач из тех, что обычно скидываю агенту и иду за кофе. Всё на Python, от одного до пяти файлов:Off-by-one в пагинации, тест падает, надо починить.
Как попасть в ответы Perplexity AI и почему эта ИИ‑модель берёт не весь текст с цитируемых страниц
Я прогнал 20 промптов через Perplexity API по три повтора, собрал 60 ответов и у каждой отсылки в тексте связал предложение ответа со страницей источника, на которую оно указывает. Дальше самое трудоёмкое: для каждой такой пары — предложение ответа и страница источника — я искал в HTML кусок текста, максимально похожий на утверждение из ответа. Из 1355 отсылок 948 привели на страницы, которые ещё открываются, и на 448 из них нашёлся пассаж — абзац, пункт списка или ячейка таблицы, — покрывающий хотя бы треть слов утверждения.
Агент пишет код. Что тогда остаётся инженеру данных?
Здравый смыслВ работе инженера данных хватает повторяющихся задач: забрать данные из API, проверить структуру, преобразовать поля, записать результат в хранилище. Вокруг этого — настройки, тесты, сообщения об ошибках и документация.Такую работу удобно поручать Агенту. Например:
LLM не должен читать логи без ограничений: безопасный MCP-шлюз для разбора сбоев
В понедельник утром пайплайн упал. В чате уже есть три версии причины: «сеть», «база опять задумалась» и «давайте просто перезапустим». Ассистент мог бы за минуту собрать список упавших задач, показать зависимые пайплайны и выдать первую гипотезу. Но для этого ему часто отдают доступ к логам, метаданным и иногда — не будем показывать пальцем — к произвольному SQL.Так делать не стоит. Достаточно, что модель прочитает токен в логе, получит инструкцию из текста ошибки или отправит в базу слишком дорогой запрос. У инженера тут должен сработать простой вопрос: «Можно. А зачем?»
Кредитный радар: LLM-воркфлоу, который каждое утро читает условия 12 банков и сам проверяет свои числа
TL;DR. Собрал воркфлоу на языковой модели, который раз в сутки обходит 34 страницы условий у 12 российских банков, сравнивает их со вчерашним снимком и публикует сводку изменений с ссылкой на источник в каждой строке, а при изменении цены пишет разбор с расчётом. Модель вызывается в четырёх точках и ни в одной не решает, что делать дальше. Цитаты, числа и статистика проверяются кодом. Каждый выпуск оценивается по 14 бинарным проверкам, метрики публичные. Стоит от 3 центов до 70 в день. Ниже устройство, проверки, evals и что он нашёл за первую неделю.
Как проверяющий ИИ испортил правильные ответы: разбор генератора учебных заданий
В задании на сортировку было слово «маши…ый». Генератор положил его в корзину «Две НН», и это верно. Проверка переложила слово в корзину «Одна Н». Вот ответ модели-арбитра, после которого это случилось, без правок, из сохранённого JSON:{ "n": 4, "a": "Одна Н", "why": "Прилагательное от «машина» с суффиксом -н-: корень оканчивается на н? Нет — «машин-» + -н- даёт «машинный»? В школьной норме пишется «машинный» (две НН), но по данному заданию основа «машин»+н… — фактически верно «машинный»." } Ответ в поле a неверный, а в объяснении модель сама приходит к «машинный». Код читал только a.
Не только PyTorch. О чём на самом деле новая книга Лоуренса Морони
Название новой книги Лоуренса Морони — «
Сорок раундов ревью на код, который уже был отревьюен: что два ИИ-ревьюера нашли друг за другом
В прошлой статье про skillmem — локальную память для кодовых агентов — я рассказывал, как чужой README мог стать правилом пользователя, и как мы закрыли это в 0.10. Тогда код прошёл два независимых ревью, и я считал, что дыра одна и она закрыта.Вчера вышел 0.11.0. Между ними — сорок раундов ревью двумя моделями с разных сторон (одна на стороне Claude, другая на стороне GPT), каждая читала код враждебно и обязана была воспроизвести находку командой, а не рассуждением. Ниже — что из этого вышло и почему я теперь не верю ни одному «чистому» ревью, пока за ним не стоит ещё одно.Правило стопа
Как я собрал бота‑команду из 11 ИИ‑юристов и что под капотом пошло не так первым же смоук‑тестом
Полтора месяца назад мне пришла претензия на 44 тысячи рублей за фото восьмилетней давности на сайте нашего отеля — типичный «фотобанковский» иск с QR‑кодом, печатью и таблицей коэффициентов. Разбирался сам, с помощью Claude, закрыл спор на 20 тысячах вместо 44 без суда и без найма юриста. Написал об этом на VC.ru — сюда, на Хабр, тащить ту же историю смысла нет, тут расскажу, как это в итоге превратилось в бота и что было интересного технически: архитектура, пять реальных багов с продакшена и то, как я срезал расходы на Claude API почти на порядок.
