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

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

@kisel_it

Я – Александр, и это мой авторский канал, где я пишу про разработку, AI и работу в айти.

Купить рекламу: https://telega.in/c/kisel_it
Subscribers
4.34K
Photos
224
Videos
13
Links
83

Showing posts older than #309 · Back to latest

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

Будущее наступило! Ура! 🥹
  • 😁 17
  • 😱 3
  • 🙏 2
  • 👎 1
Post #307 1.01K
🥷 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 мимо всего.

Такие дела.
  • 😱 7
  • 🔥 2
  • 😢 2
Post #306 867
Видимо в этом году нас удивит не только Google. Из-за ошибки в настройке CMS Anthropic слила 3000 внутренних документов в открытый доступ. И там было кое-что интересное про их новую модель.

Она засветилась там под именем «Claude Mythos». Так же появился новый таер выше Opus - «Capybara». Anthropic по итогу подтвердил существование модели, назвав её «step change» в возможностях и «самой мощной из когда-либо созданных ими».

По данным утёкшего черновика, по сравнению с Claude Opus 4.6 новая модель показывает значительно более высокие результаты в программировании, академическом рассуждении и кибербезопасности.

При этом в черновике прямо говорится, что модель «очень дорога в обслуживании» и компания работает над повышением эффективности перед любым массовым релизом.

В утёкшем же черновике Anthropic заявляет, что модель «создаёт беспрецедентные риски кибербезопасности» и способна находить и эксплуатировать уязвимости значительно быстрее защитников.

Как думаете, уже пора начинать волноваться? 🙊
  • 👍 8
  • ❤ 3
  • 🫡 2
Post #305 1.04K
Нежданно-негаданно. Вот так вот вдруг Google выкатил TurboQuant — и это, возможно, главная новость с начала года в ML.

Освежим в памяти: когда LLM ведёт с тобой длинный диалог, она хранит в памяти GPU «заметки» обо всём, что уже обсудили. Это называется KV-кэш, и именно он сжирает всю память при длинных промптах.

TurboQuant сжимает этот кэш в 6 раз. Ускоряет вычисления до 8x. Без потери качества. Без дообучения модели. Просто подключил - и работает.

Открытого кода от Google пока нет, но статья уже принята на ICLR 2026.

Сейчас на потребительской GPU с 24 ГБ VRAM можно крутить 7B-модель, но с контекстом 4-8k. Если KV-кэш ужимается в 6 раз, тот же ноутбук тянет 32-64k контекста. Для локальных ассистентов и всего, где важна приватность - это качественный скачок, который открывает много новых дорог новым инструментам. Миллион токенов контекста перестанут быть роскошью. Возможно мы увидим модели с контекстом на порядки выше.

Что ж, посмотрим что нас ждёт дальше.
  • ❤ 9
  • 👍 5
  • 🔥 5
Post #304 1.03K
Зелёные тесты ≠ хорошие тесты

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

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

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

Ждём, когда мутанты станут умнее.
  • ❤ 11
  • 👍 7
  • 🔥 3
Post #303 969
ИИ хотя бы предупреждает, что может ошибаться. Интернет - нет. Прежде чем бояться галлюцинаций, подумайте, сколько горе-эксперты написали чепухи, которой люди верят до сих пор.

Раньше можно было всему слепо верить, потому что писали люди? Нет, нельзя. Получается, что ничего не изменилось?
  • 👍 8
  • ❤ 4
Post #302 1.17K
Есть тут у нас пользователи Клод Кода? Расскажите, какие используете скилы.
Они недавно даже плагин для их создания/тестирования выкатили. Но... Я так и не придумал ни одного полезного юзкейса.
  • 👍 4
  • 👎 1
Post #301 1.08K
Сегодня участвовал в олимпиаде по программированию, но не простой. Это была битва на llm-ках. Что я могу сказать? Давно я с таким интересом не решал задачки. А ведь никто такое не проводит, хотя это самый логичный шаг - хватит запрещать использовать то, что все и так будут использовать Всем станет от этого только легче и интереснее.

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

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

Что я могу сказать? Опыт крайне интересный. Классическая зубрежка алгоритмов отходит на второй план всё сильнее и сильнее. А новые подходы позволяют добиться такой эффективности, на достижение которой раньше бы просто не хватило времени.
  • 👍 10
  • 🔥 4
  • 💯 2
  • 👎 1
Post #299 1.05K
⚡️⚡️⚡️РАЗРАБОТЧИКИ ВСЁ ⚡️⚡️⚡️

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

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

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

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

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

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

Что думаете?
  • 👍 9
  • ❤ 4
  • 💯 3
Post #298 936
⚡️⚡️⚡️ВАЙБКОДИНГ ВСЁ ⚡️⚡️⚡️

Там ночью по датацентру в ОАЭ прилетело, Claude лежит уже больше 7 часов 😐
  • 😢 8
  • 😁 6
  • 🤯 2
  • 👍 1
  • 😱 1
Post #297 1.17K
Вышло любопытное исследование 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
  • 👍 7
Post #296 1.06K
Совершенно случайно вывел новый термин.

КуКлод-разработчик - человек, который смотрит, как Клод пишет код в его проекте.
  • 😁 12
Post #295 1.23K
Да, чувствую себя именно так 😂
  • 😁 5
  • ❤ 3
  • 👍 1
Post #293 1.32K
Для меня всегда было загадкой, почему core-команда Python так и не родила нормальный инструмент, чтобы этим Python пользоваться. Это чуть ли не самое главное в языке. Входная точка, через которую проходит каждый разработчик десятки тысяч раз.

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

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

И кажется это еще не конец. У кого нибудь есть этому объяснение?
  • 👾 6
  • ❤ 2
  • 🤯 2
Post #292 1.11K
Наконец-то распробовал 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, который в итоге затащили вообще везде и всюду.
  • 👍 9
  • ❤ 3
  • 🔥 3
Post #291 797
ChatGPT оказывается умеет в стиль желтушных СМИ. Собрал для вас последние актуальные новости 😂
  • 👍 2
  • 😁 1
  • 🤮 1
Post #289 864
И в догоночку. Как вам концепт первого в мире вайббука? Ничего лишнего 💳
  • ❤ 2
  • 🤡 1
  • 💯 1
Post #288 884
Отладка кода в наше время всё больше напоминает мне слот-машину.

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

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

Это точно еще можно назвать "разработкой"? 🤔
  • 😁 2
  • 🥴 2
Post #287 813
Подлый Outlook новой версии теперь все письма выкачивает на сервера Майков. Раньше данными с почты распоряжался гугл. Ладно, с этим кое-как смирились. Но зачем программе для просмотра писем требуется ПОЛНЫЙ МАТЬ ЕГО ДОСТУП к почтовому ящику? Причем там  абсолютно безумное пользовательское соглашение, без ограничений по сбору и использованию данных.

На наших глазах датамайнинг активно прогрессирует, доходя до полной шизофрении. Жду момент, когда нужно будет залогинится на холодильнике для показа таргетированной рекламы. Ну и доступ к почте дать тоже. На всякий случай. Чтобы обеспечить более персонализированный опыт! Ведь это всё еще забота о пользователе, правильно?


🔛 @kisel_it

#технологии@kisel_it
  • 😁 7
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →