Forwarded from Олимпиада по программированию
Алгоритмы & ML: регистрация открыта!
30 мая с 15:00 до 19:30 мск приходите участвовать в олимпиаде по программированию онлайн или офлайн в кластере «Ломоносов» в Москве.
Эта олимпиада для инженеров, разработчиков, аналитиков из разных IT-компаний, а также студентов старших курсов. Здесь каждый пишет свой код, а после на отдельной онлайн-встрече может увидеть решения других участников и узнать лучшие практики.
🔵 Формат — только индивидуально.
🔵 Время на решение задач — два часа.
На выбор будет два трека:
1️⃣ Алгоритмы — пять задач: простые, средние и одна оптимизационная. Способ решения — самостоятельно, без помощи ИИ.
2️⃣ ML — три хардкорные оптимизационные задачи, можно пользоваться ИИ-помощниками.
В каждом треке определим победителей и наградим призами :)
Мы всегда рады новым участникам в нашем олимпиадном комьюнити. Приходите сами и зовите друзей!
Зарегистрироваться
30 мая с 15:00 до 19:30 мск приходите участвовать в олимпиаде по программированию онлайн или офлайн в кластере «Ломоносов» в Москве.
Эта олимпиада для инженеров, разработчиков, аналитиков из разных IT-компаний, а также студентов старших курсов. Здесь каждый пишет свой код, а после на отдельной онлайн-встрече может увидеть решения других участников и узнать лучшие практики.
На выбор будет два трека:
В каждом треке определим победителей и наградим призами :)
Мы всегда рады новым участникам в нашем олимпиадном комьюнити. Приходите сами и зовите друзей!
Зарегистрироваться
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍3
Снова олимпиада. Собираюсь на трек ML. В этот раз оффлайн, давно пора посмотреть на кластер Ломоносов. В этот раз хочу проверить новые подходы решения задач с быстрыми моделями (haiku, flash 3,5 и т.д).
Предыдущий опыт с Opus 4.6 и Gemini 3 Pro был относительно неудачным. Сложные задачи триггерят режим thinking, который со временем выпадает в таймаут через 20-30 минут. Причем не оставляет ни намёка на решение. Колоссальная потеря времени. А вот постепенная оптимизация/эволюция слабого решения быстрыми моделями показала себя намного лучше. Чтож, проверим.
Кто с Москвы - присоединяйтесь оффлайн. Если нет - приходите онлайн.
Предыдущий опыт с Opus 4.6 и Gemini 3 Pro был относительно неудачным. Сложные задачи триггерят режим thinking, который со временем выпадает в таймаут через 20-30 минут. Причем не оставляет ни намёка на решение. Колоссальная потеря времени. А вот постепенная оптимизация/эволюция слабого решения быстрыми моделями показала себя намного лучше. Чтож, проверим.
Кто с Москвы - присоединяйтесь оффлайн. Если нет - приходите онлайн.
❤9👍5🔥4
Как ИИ помог восстановить доступ к крипто-кошельку, на котором было $400к. Прошу внимания, история достойная.
В студенческие годы один товарищ купил 5 BTC по $250. И однажды под кайфом решил сменить пароль. А потом его забыл. Десять лет эти пять биткоинов пылились на кошельке. И дорожали, дорожали, дорожали. К 2026 году они стали стоить четыреста штук баксов. И это замечательно! Только вот пароля нет. И ничего не помогало его найти.
Последняя надежда была на Claude. Ему поручили копаться в мусоре (изучить все файлы на старом ноутбуке). И, о чудо, на этой свалке нашёлся старый бэкап кошелька - тот, что был сделан ещё до смены пароля. Только вот старый файл с старым паролем не открылся... Btcrecover уверенно выдавала ошибку "Пароль неправильный". Батька Claude почесал голову, выругался и полез разбираться дальше. Залез далеко, аж в исходники btrecover. Там нашелся баг: утилита неправильно склеивала внутренний ключ кошелька с пользовательским паролем. И уже после этого фикса бэкап открылся с первой попытки.
Упорство итруд Claude - ключ от кошелька найдут. А еще пару лет назад мы могли о таком только мечтать. А сейчас вон, драйвера чинят, игры старые портируют, теперь вон и кошельки восстанавливают. Круто!
В студенческие годы один товарищ купил 5 BTC по $250. И однажды под кайфом решил сменить пароль. А потом его забыл. Десять лет эти пять биткоинов пылились на кошельке. И дорожали, дорожали, дорожали. К 2026 году они стали стоить четыреста штук баксов. И это замечательно! Только вот пароля нет. И ничего не помогало его найти.
Последняя надежда была на Claude. Ему поручили копаться в мусоре (изучить все файлы на старом ноутбуке). И, о чудо, на этой свалке нашёлся старый бэкап кошелька - тот, что был сделан ещё до смены пароля. Только вот старый файл с старым паролем не открылся... Btcrecover уверенно выдавала ошибку "Пароль неправильный". Батька Claude почесал голову, выругался и полез разбираться дальше. Залез далеко, аж в исходники btrecover. Там нашелся баг: утилита неправильно склеивала внутренний ключ кошелька с пользовательским паролем. И уже после этого фикса бэкап открылся с первой попытки.
Упорство и
1👍11 8🔥6
Прогнал тестирование проекта через Claude прямо в браузере
Дал Клоду доступ к Chrome (через плагин Claude in Chrome) и одну задачу: «прощёлкай весь функционал и составь отчёт о работоспособности». После одной из самых жирных фич у меня на проекте много чего отвалилось — хотел понять масштаб.
Что в итоге получилось:
— прощёлкал всю админку, публичную часть
— проверил лендинг: демо, тарифы, форму заявки
— залез в консоль и Network, померил тайминги через Performance API
— сложил всё в
И нашёл вполне реальные вещи, не «вода»:
🔴 403 на прямом заходе/F5 на вложенных страницах админки (nginx без fallback на index.html)
🔴 404 на фоновом паттерне темы — фон просто не грузился
🔴 сломанный эндпоинт конфига чата, который ещё и 440мс впустую жрёт
🟡 пустое демо на лендинге первые 6 секунд + hydration mismatch в Nuxt
🟡 опечатки, сброс контекста после F5
Отдельно порадовало, что он сам додумался перепроверять свои же выводы: сначала решил, что сломан фильтр (пустая выдача), а потом понял, что это была комбинация «поиск + фильтр» без совпадений, и переиграл вердикт. Не просто «вижу пусто → баг».
И конечно же понравилось, что в чате остались скриншоты всех найденных артефактов. Удобно!)
Честно про минусы:
⚠️ вкладка под автоматизацией иногда подвисала, скриншоты отваливались по таймауту
⚠️ paint-метрики (FCP/LCP) врут, потому что фоновая вкладка троттлится — для честных цифр всё равно нужен Lighthouse руками
Вывод: как первый проход QA по живому продукту — неожиданно полезно. Не заменяет ручное тестирование и автотесты, но за один заход выдаёт приоритизированный список «что пойти чинить». Я за полчаса получил карту поломок, на которую сам бы потратил вечер.
#claude
Дал Клоду доступ к Chrome (через плагин Claude in Chrome) и одну задачу: «прощёлкай весь функционал и составь отчёт о работоспособности». После одной из самых жирных фич у меня на проекте много чего отвалилось — хотел понять масштаб.
Что в итоге получилось:
— прощёлкал всю админку, публичную часть
— проверил лендинг: демо, тарифы, форму заявки
— залез в консоль и Network, померил тайминги через Performance API
— сложил всё в
test_report.md с приоритизацией баговИ нашёл вполне реальные вещи, не «вода»:
🔴 403 на прямом заходе/F5 на вложенных страницах админки (nginx без fallback на index.html)
🔴 404 на фоновом паттерне темы — фон просто не грузился
🔴 сломанный эндпоинт конфига чата, который ещё и 440мс впустую жрёт
🟡 пустое демо на лендинге первые 6 секунд + hydration mismatch в Nuxt
🟡 опечатки, сброс контекста после F5
Отдельно порадовало, что он сам додумался перепроверять свои же выводы: сначала решил, что сломан фильтр (пустая выдача), а потом понял, что это была комбинация «поиск + фильтр» без совпадений, и переиграл вердикт. Не просто «вижу пусто → баг».
И конечно же понравилось, что в чате остались скриншоты всех найденных артефактов. Удобно!)
Честно про минусы:
⚠️ вкладка под автоматизацией иногда подвисала, скриншоты отваливались по таймауту
⚠️ paint-метрики (FCP/LCP) врут, потому что фоновая вкладка троттлится — для честных цифр всё равно нужен Lighthouse руками
Вывод: как первый проход QA по живому продукту — неожиданно полезно. Не заменяет ручное тестирование и автотесты, но за один заход выдаёт приоритизированный список «что пойти чинить». Я за полчаса получил карту поломок, на которую сам бы потратил вечер.
#claude
1✍5🔥3❤2
Вдохновляемся ИИ-поэзией после тяжёлого рабочего дня.
Оригинал то знаем?
Оригинал то знаем?
Послушайте!
Ведь, если токены сжигают —
значит — это кому-нибудь нужно?
Значит — кто-то хочет,
чтобы ответы были?
Значит — кто-то
называет эти миллионы запросов
не «тратой денег»,
а автоматизацией?
И, надрываясь
в метелях ночного вайбкодинга,
врывается в API,
боится, что лимит кончился,
платит,
обновляет подписку дрожащей рукой,
просит —
чтоб обязательно
достроило MVP!
клянётся —
не перенесёт
эту безнейросетную муку.
А после
ходит тревожный,
но спокойный наружно.
Говорит кому-то:
— Ведь теперь деплой не страшен?
Да?..
Послушайте!
Ведь, если токены сжигают —
значит — это кому-нибудь нужно?
😁10🐳4❤2🤓2
Для ресёрча к постам иногда прогоняю тему сразу через несколько разных моделей. Одна лучше ищет детали, другая помогает проверить факты, третья подкидывает неожиданные углы для рассказа. Удобно, когда это можно делать в одном месте, не прыгая между сервисами. В последнее время для такого часто открываю Umnik AI. Claude к примеру намного хуже справляется с поиском по ru ресурсам, а вот chatgpt - намного лучше. Но они часто очень "сдержанные", поэтому острые вопросы удобнее разобрать с Гроком. И вот уже в сумме получается +- объективно. Так и живём.
👍4🤔2❤1🔥1
Принёс новый GitHub-тренд для тех, кто работает с большими проектами - CodeGraph.
Идея простая: CodeGraph (ссылка на репо) заранее строит для агента «карту проекта». Он индексирует репозиторий, вытаскивает функции, классы, импорты, вызовы и зависимости, складывает всё в локальную SQLite-базу, а потом отдаёт агентам через MCP.
То есть вместо привычного ритуала
Собственно, никакой магии тут нет, и польза весьма приземлённая. У больших проектов есть ощутимый налог на разведку: каждый новый агент сначала пытается понять, где что лежит, какие файлы важные, кто кого вызывает и где начинается нужный flow. Память и карта проекта в markdown тут не сильно спасает. Когда в репозитории сотни или тысячи файлов, агент может сжечь кучу токенов просто на то, чтобы осмотреться.
А раздутый контекст - это не только дороже и медленнее. Это ещё и лишний шум: модель тащит за собой мусор, который насобирала по пути. В итоге её «интеллект» внезапно начинает напоминать меня после третьего созвона подряд.
По собственным бенчмаркам автора на 7 open-source проектах CodeGraph дал примерно 35% экономии стоимости, 57% меньше токенов, 46% быстрее ответы и 71% меньше tool calls. Цифры красивые, но пока это именно авторский benchmark, а не независимое исследование.
Полноценных независимых исследований именно CodeGraph пока нет - инструмент свежий. Судя по релизам, он появился буквально в мае 2026 года и сейчас активно допиливается. Но сама идея не новая. Уже много лет существуют статические анализаторы, графы вызовов и графы зависимостей. Теперь этим всем пытаются научить пользоваться AI-агентов, потому что каждый лишний обход проекта - это токены, деньги и время.
Сразу задаюсь вопросом: почему это не стало мейнстримом раньше?
Думаю, основная причина в том, что раньше боль была слабее. AI и до этого умел писать код, объяснять файлы и помогать с рефакторингом, но чаще человек сам приносил ему контекст: вот файл, вот функция, вот ошибка. С агентами сценарий поменялся: теперь им всё чаще отдают задачу целиком - «разберись в проекте, найди нужную логику, измени её и проверь последствия».
И тут внезапно значимая часть работы уходит не на кодинг, а на разведку проекта. Поэтому старая идея code intelligence снова стала актуальной. Это привычные IDE-фичи вроде Go to definition, Find usages и Rename symbol, только теперь не для человека, а для агента. CodeGraph пытается дать ему не простыню файлов, а карту связей внутри проекта.
Но открытых вопросов всё ещё много. Как сделать такой граф универсальным, если в реальных проектах есть динамические импорты, DI-контейнеры, ORM, generated code и магия фреймворков? Как заставить агента действительно пользоваться графом, а не продолжать бегать через grep/read по привычке?
Похожие подходы уже проверяли в исследованиях. Например, в препринте про Codebase-Memory использовали похожую связку: Tree-sitter, knowledge graph и MCP. Результат ожидаемый: токенов уходит сильно меньше, tool calls тоже меньше, но качество ответов может просесть, если вопрос требует не карты проекта, а внимательного чтения конкретной реализации.
То есть это снова не «серебряная пуля» для разработки. Но инструмент может быть полезным для больших репозиториев.
Идея простая: CodeGraph (ссылка на репо) заранее строит для агента «карту проекта». Он индексирует репозиторий, вытаскивает функции, классы, импорты, вызовы и зависимости, складывает всё в локальную SQLite-базу, а потом отдаёт агентам через MCP.
То есть вместо привычного ритуала
grep → read → grep → read → grep → read агент может запросить готовый граф кода.Собственно, никакой магии тут нет, и польза весьма приземлённая. У больших проектов есть ощутимый налог на разведку: каждый новый агент сначала пытается понять, где что лежит, какие файлы важные, кто кого вызывает и где начинается нужный flow. Память и карта проекта в markdown тут не сильно спасает. Когда в репозитории сотни или тысячи файлов, агент может сжечь кучу токенов просто на то, чтобы осмотреться.
А раздутый контекст - это не только дороже и медленнее. Это ещё и лишний шум: модель тащит за собой мусор, который насобирала по пути. В итоге её «интеллект» внезапно начинает напоминать меня после третьего созвона подряд.
По собственным бенчмаркам автора на 7 open-source проектах CodeGraph дал примерно 35% экономии стоимости, 57% меньше токенов, 46% быстрее ответы и 71% меньше tool calls. Цифры красивые, но пока это именно авторский benchmark, а не независимое исследование.
Полноценных независимых исследований именно CodeGraph пока нет - инструмент свежий. Судя по релизам, он появился буквально в мае 2026 года и сейчас активно допиливается. Но сама идея не новая. Уже много лет существуют статические анализаторы, графы вызовов и графы зависимостей. Теперь этим всем пытаются научить пользоваться AI-агентов, потому что каждый лишний обход проекта - это токены, деньги и время.
Сразу задаюсь вопросом: почему это не стало мейнстримом раньше?
Думаю, основная причина в том, что раньше боль была слабее. AI и до этого умел писать код, объяснять файлы и помогать с рефакторингом, но чаще человек сам приносил ему контекст: вот файл, вот функция, вот ошибка. С агентами сценарий поменялся: теперь им всё чаще отдают задачу целиком - «разберись в проекте, найди нужную логику, измени её и проверь последствия».
И тут внезапно значимая часть работы уходит не на кодинг, а на разведку проекта. Поэтому старая идея code intelligence снова стала актуальной. Это привычные IDE-фичи вроде Go to definition, Find usages и Rename symbol, только теперь не для человека, а для агента. CodeGraph пытается дать ему не простыню файлов, а карту связей внутри проекта.
Но открытых вопросов всё ещё много. Как сделать такой граф универсальным, если в реальных проектах есть динамические импорты, DI-контейнеры, ORM, generated code и магия фреймворков? Как заставить агента действительно пользоваться графом, а не продолжать бегать через grep/read по привычке?
Похожие подходы уже проверяли в исследованиях. Например, в препринте про Codebase-Memory использовали похожую связку: Tree-sitter, knowledge graph и MCP. Результат ожидаемый: токенов уходит сильно меньше, tool calls тоже меньше, но качество ответов может просесть, если вопрос требует не карты проекта, а внимательного чтения конкретной реализации.
То есть это снова не «серебряная пуля» для разработки. Но инструмент может быть полезным для больших репозиториев.
1✍6❤4👍3
Себе вот уже накатил CodeGraph на один из своих проектов. Установка оказалась довольно приятной.
Установка запускается одной командой:
Дальше установщик сам спрашивает, для каких агентов всё настроить. У меня он нашёл Claude Code, Cursor, Codex CLI, Gemini CLI и Antigravity IDE. Для Claude Code, Cursor и Gemini конфиги создал сам, а Codex CLI и Antigravity пропустил, потому что они не поддержали локальную установку в конкретный проект.
Из полезного: CodeGraph сам ставит CLI в PATH, создаёт
После этого он сразу просканировал проект: нашёл 260 файлов, проиндексировал 239 и вытащил 2 529 символов. Для моего проекта это заняло меньше минуты - не гигантский монорепозиторий, но уже достаточно, чтобы агенту было куда ходить не через слепой grep.
Мой вывод: на больших репозиториях попробовать точно стоит. Особенно если агент уже вторую неделю жрёт лимиты, как будто его дома не кормят🍴
Установка запускается одной командой:
npx @colbymchenry/codegraph
Дальше установщик сам спрашивает, для каких агентов всё настроить. У меня он нашёл Claude Code, Cursor, Codex CLI, Gemini CLI и Antigravity IDE. Для Claude Code, Cursor и Gemini конфиги создал сам, а Codex CLI и Antigravity пропустил, потому что они не поддержали локальную установку в конкретный проект.
Из полезного: CodeGraph сам ставит CLI в PATH, создаёт
.codegraph/, добавляет MCP-конфиги и правила для агентов. Например, для Claude Code появились .mcp.json, .claude/settings.json и .claude/CLAUDE.md, для Cursor - .cursor/mcp.json и .cursor/rules/codegraph.mdc, для Gemini - .gemini/settings.json и GEMINI.md.После этого он сразу просканировал проект: нашёл 260 файлов, проиндексировал 239 и вытащил 2 529 символов. Для моего проекта это заняло меньше минуты - не гигантский монорепозиторий, но уже достаточно, чтобы агенту было куда ходить не через слепой grep.
Мой вывод: на больших репозиториях попробовать точно стоит. Особенно если агент уже вторую неделю жрёт лимиты, как будто его дома не кормят
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤4
Claude Opus 4.8 вышел. И самое интересное — не бенчмарки.
Anthropic обновила Opus: модель стала сильнее в кодинге, reasoning и агентских задачах, цена осталась прежней — $5 / $25 за миллион токенов.
Но главный апдейт - в поведении.
Opus 4.8, по словам Anthropic, чаще признаёт неопределённость, лучше ловит собственные ошибки и примерно в 4 раза реже пропускает баги в написанном коде без замечаний.
Плюс в Claude Code появился dynamic workflows: Claude может разбивать большую задачу на десятки/сотни параллельных subagents и тащить большие миграции, аудиты и рефакторинги.
Кажется, AI-гонка постепенно смещается от слепой гонки за бенчмарками к более ощутимым и близким любому человеку метрикам. К примеру: "наша модель модель меньше врёт", "лучше проверяет себя", "может дольше работать без человека".
И вот это уже гораздо интереснее очередного плюсика в бенче.
Конечно же не забыли напомнить и про Mythos:
Хочется верить, что в ближайший месяц-полтора уже выпустят модель для всех.
Anthropic обновила Opus: модель стала сильнее в кодинге, reasoning и агентских задачах, цена осталась прежней — $5 / $25 за миллион токенов.
Но главный апдейт - в поведении.
One of the most prominent improvements in Opus 4.8 is its honesty
Opus 4.8, по словам Anthropic, чаще признаёт неопределённость, лучше ловит собственные ошибки и примерно в 4 раза реже пропускает баги в написанном коде без замечаний.
Плюс в Claude Code появился dynamic workflows: Claude может разбивать большую задачу на десятки/сотни параллельных subagents и тащить большие миграции, аудиты и рефакторинги.
Кажется, AI-гонка постепенно смещается от слепой гонки за бенчмарками к более ощутимым и близким любому человеку метрикам. К примеру: "наша модель модель меньше врёт", "лучше проверяет себя", "может дольше работать без человека".
И вот это уже гораздо интереснее очередного плюсика в бенче.
Конечно же не забыли напомнить и про Mythos:
we expect to be able to bring Mythos-class models to all our customers in the coming weeks.
Хочется верить, что в ближайший месяц-полтора уже выпустят модель для всех.
❤8👍3🔥3
Кажется у меня новое хобби... Генерировать новости под стихи Маяковского. Как же круто.
ОДА НА OPUS 4.8
Слушайте!
Граждане
двадцать шестого года —
из кода,
из ночи,
из кофе остывшего —
встаёт
не машина,
не просто метОда,
а Опус!
Четыре!
И восемь!
вышедший!
Я звал его —
он отвечал мне строчками,
не мямлил,
не путал,
не лез в чепуху.
Где раньше я бился
над багом
до точки я,
теперь —
раз-два! —
и поправка вверху.
Товарищ процессор,
давай,
разгоняйся!
Мы вместе
запустим
стартап до небес!
Проект мой
ракетою
в космос врезается —
а Опус
внизу
подаёт ему вес.
Не спать!
Не сдаваться!
Гори, предприятие!
Пускай говорят,
что работа —
тюрьма.
Я выйду!
Я брошу!
И — солнце! — объятия! —
останусь
один
на один
с новым Опусом.
Да!
🔥8👍3👏2❤1🤩1
.git/info/exclude — личный .gitignore, который не уезжает в репу
Знакомая боль: пробуешь у себя в проекте новый инструмент - и каждый раз git status шумит этими файлами, рискуешь случайно закоммитить лишнего. У меня там и .cursor, и agent.md от Codex, и claude.md от клода, и много чего еще... С codegraph еще и его папка появилась.
В проектный .gitignore это добавлять нежелательно. Если каждый раз туда добавлять всё больше и больше - он превратится в огромную свалку. Плюс в больших проектах пока твой .ginignore разойдется по develop/main - пройдет вечность, которую ты будешь страдать.
А оказывается, у git ровно для этого есть встроенная штука — .git/info/exclude.
Это файл внутри .git/, синтаксис как у .gitignore, но он:
- не коммитится (живёт в .git/, а .git/ сам по себе не версионируется);
- виден только тебе;
- работает в этом конкретном клоне репозитория.
Пример. Открываешь .git/info/exclude и пишешь туда что угодно:
- CLAUDE.md
- AGENTS.md
- .cursor/
- experiments/
Всё - git status чист, ничего случайно не уедет в PR.
Бонус: есть глобальный игнор на все репы
Если те же файлы засоряют тебе вообще все проекты - можно настроить глобально:
В этот файл кладём универсальные паттерны (CLAUDE.md, .idea/, .DS_Store).
Не знаю почему я не нагуглил это раньше. Такая маленькая фича, а такая полезная.
Знакомая боль: пробуешь у себя в проекте новый инструмент - и каждый раз git status шумит этими файлами, рискуешь случайно закоммитить лишнего. У меня там и .cursor, и agent.md от Codex, и claude.md от клода, и много чего еще... С codegraph еще и его папка появилась.
В проектный .gitignore это добавлять нежелательно. Если каждый раз туда добавлять всё больше и больше - он превратится в огромную свалку. Плюс в больших проектах пока твой .ginignore разойдется по develop/main - пройдет вечность, которую ты будешь страдать.
А оказывается, у git ровно для этого есть встроенная штука — .git/info/exclude.
Это файл внутри .git/, синтаксис как у .gitignore, но он:
- не коммитится (живёт в .git/, а .git/ сам по себе не версионируется);
- виден только тебе;
- работает в этом конкретном клоне репозитория.
Пример. Открываешь .git/info/exclude и пишешь туда что угодно:
- CLAUDE.md
- AGENTS.md
- .cursor/
- experiments/
Всё - git status чист, ничего случайно не уедет в PR.
Бонус: есть глобальный игнор на все репы
Если те же файлы засоряют тебе вообще все проекты - можно настроить глобально:
git config --global core.excludesFile ~/.gitignore_globalВ этот файл кладём универсальные паттерны (CLAUDE.md, .idea/, .DS_Store).
Не знаю почему я не нагуглил это раньше. Такая маленькая фича, а такая полезная.
👍9🔥5❤2💯2
Новый день - новый скилл. Разберем
Он проходит по недавно изменённым файлам и ищет, что можно упростить. Спавнит трёх параллельных агентов под разными углами - неиспользуемые импорты, лишние переменные, шанс вытащить общую логику, переусложнённые условия. Найденное чинит сам.
Можно сузить фокус:
Запускается локально. В отличие от /ultrareview бесплатный и быстрый, по ощущениям ближе к мини-ревью.
Лучше всего работает сразу после крупного рефакторинга или после того, как принял большой батч AI-сгенерированного кода. Именно там накапливаются мелкие огрехи, которые поодиночке незаметны
Хорошая привычка - дёргать
#claude
/simplify для Claude Code.Он проходит по недавно изменённым файлам и ищет, что можно упростить. Спавнит трёх параллельных агентов под разными углами - неиспользуемые импорты, лишние переменные, шанс вытащить общую логику, переусложнённые условия. Найденное чинит сам.
Можно сузить фокус:
/simplify focus on memory efficiency или /simplify focus on error handling. Полезно, когда знаешь, где у изменений шероховатости, но хочешь, чтобы Claude довёл до ума деталиЗапускается локально. В отличие от /ultrareview бесплатный и быстрый, по ощущениям ближе к мини-ревью.
Лучше всего работает сразу после крупного рефакторинга или после того, как принял большой батч AI-сгенерированного кода. Именно там накапливаются мелкие огрехи, которые поодиночке незаметны
Хорошая привычка - дёргать
/simplify перед коммитом после серьёзных изменений. Дешевле, чем ловить те же вещи на code review.#claude
👍4🔥3❤2
Forwarded from Олимпиада по программированию
Победители в треке «Алгоритмы»:
🥇 1 место — Филонец Антон, Яндекс, МИФИ🥈 2 место — Москвин Александр, МГУ🥉 3 место — Тихонов Дмитрий, Яндекс
Победители в треке «ML»:
🥇 1 место — Киселев Александр, Positive Technologies🥈 2 место — Коротаев Вадим, Positive Technologies🥉 3 место — Ларин Иван, Сбербанк, МФТИ
Поздравляем!
Please open Telegram to view this post
VIEW IN TELEGRAM
1🎉8🔥5👏4
🏆 Как я взял первое место на олимпиаде по оптимизации — и почему дело было не в алгоритмах
Победа решилась 0.005 балла. Серьёзно - после нескольких часов борьбы общий зачёт разделили пять тысячных. И вот что я вынес из этой гонки: на таком уровне выигрывает не тот, кто придумал самый умный алгоритм, а тот, у кого правильно выстроен процесс работы.
Несколько принципов, которые реально решили исход 👇
1. Итерации важнее озарений. Учёл эту ошибку из прошлого опыта. Я не пытался родить идеальное решение сразу. Начинал с малого. Рабочее, пусть и не самое оптимальное решение - отличная база. Каждую задачу я прогонял через лесенку версий: простой рабочий вариант → отправил → улучшил → отправил снова. Побеждает число честных итераций, а не глубина раздумий.
2. Учимся на ошибках. Архитектура строится так, чтобы учиться на своих ошибках и делать выводы: после того, как сформирован валидный базовый ответ, он служит основой и обоснованием для будущих улучшений. Каждая итерация - это ценная информация. Всё это позволяет пробовать больше. Без страха и с чувством азарта.
3. Разные модели - разное решение. В какой-то момент Claude начал упираться в потолок своих знаний. На помощь приходят другие модели, которые учились на других данных. Это отличный источник инсайтов и альтернативных подходов.
Любопытный момент: задачу B по очкам я проиграл - другой участник сделал её лучше. Но ровный, дисциплинированный процесс по всем задачам сразу всё таки вытащил общую победу.
Вывод: запускай больше, измеряй, фиксируй выводы. Правильный флоу бьёт зубрёжку. ⚡️
Победа решилась 0.005 балла. Серьёзно - после нескольких часов борьбы общий зачёт разделили пять тысячных. И вот что я вынес из этой гонки: на таком уровне выигрывает не тот, кто придумал самый умный алгоритм, а тот, у кого правильно выстроен процесс работы.
Несколько принципов, которые реально решили исход 👇
1. Итерации важнее озарений. Учёл эту ошибку из прошлого опыта. Я не пытался родить идеальное решение сразу. Начинал с малого. Рабочее, пусть и не самое оптимальное решение - отличная база. Каждую задачу я прогонял через лесенку версий: простой рабочий вариант → отправил → улучшил → отправил снова. Побеждает число честных итераций, а не глубина раздумий.
2. Учимся на ошибках. Архитектура строится так, чтобы учиться на своих ошибках и делать выводы: после того, как сформирован валидный базовый ответ, он служит основой и обоснованием для будущих улучшений. Каждая итерация - это ценная информация. Всё это позволяет пробовать больше. Без страха и с чувством азарта.
3. Разные модели - разное решение. В какой-то момент Claude начал упираться в потолок своих знаний. На помощь приходят другие модели, которые учились на других данных. Это отличный источник инсайтов и альтернативных подходов.
Любопытный момент: задачу B по очкам я проиграл - другой участник сделал её лучше. Но ровный, дисциплинированный процесс по всем задачам сразу всё таки вытащил общую победу.
Вывод: запускай больше, измеряй, фиксируй выводы. Правильный флоу бьёт зубрёжку. ⚡️
2👍5🔥5❤3💯3👎1
А вы еще помните, как было?
Падает ошибка. Ты читаешь трейсбек снизу вверх, цепляешься за знакомое слово, криво копируешь часть из терминала. Половину строки, с лишним пробелом. Открываешь Google.
Первая ссылка ведёт на StackOverflow. Вопрос 2014 года. Принятый ответ заминусован, а рабочий лежит третьим снизу. Сорок голосов, комментарий «this saved my life».
Ты его даже не копируешь, потому что случай всё равно другой. Но ты уже понял, в чём было дело.
Иногда уходишь на старый форум, на 23 страницу давно заброшенной темы. Последнее сообщение датировано 2015 годом. Аватарки битые, половина ссылок ведёт в никуда. И вдруг там, между «спасибо, помогло» и «у меня то же самое», сидит человек, который разобрал твою проблему по косточкам. Для себя. Не зная, что однажды его ответ спасёт кого-то ещё.
А иногда не находишь вообще ничего. Везде посмотрел, и пусто.
Чёрт с ним, спрошу сам.
Сидишь, формулируешь вопрос. Подбираешь слова. Прикладываешь минимальный пример, потому что иначе заминусуют. И сама эта формулировка наполовину чинит тебе мозги.
Жмёшь «отправить». Ждёшь. Обновляешь вкладку. И вот он, ответ от незнакомца, которому просто не всё равно.
Сейчас ты выделяешь трейсбек, не дочитав до конца, и пишешь: «почини».
И он чинит.
Работает. Тесты зелёные. Можно идти дальше.
Но где-то в этот момент из профессии исчезает важная часть ритуала. Та самая, где ты не просто получал ответ, а прожёвывал проблему. Злился, тупил, копался в чужих обсуждениях и постепенно начинал понимать, что вообще происходит.
Раньше ошибка была дверью. Сейчас она всё чаще становится всплывающим окном, которое хочется закрыть как можно быстрее.
И в этом есть что-то страшное.
Профессия программиста всегда держалась именно на привычке разбираться. На внутреннем упрямстве: «я хочу понять, почему оно сломалось».
А теперь у нас появился идеальный способ этого не делать.
Да, мы стали быстрее. Да, мы стали продуктивнее. Да, назад никто не пойдёт.
Но вместе с болью отладки мы выкидываем и кое что важное.
И, кажется, однажды мы проснёмся в мире, где код всё ещё пишется, ошибки всё ещё чинятся, продукты всё ещё выкатываются, но всё меньше людей действительно понимают, как это работает.
Вот это и пугает.
Не то, что ИИ заберёт работу.
А то, что он оставит нам работу, но постепенно заберёт профессию.
Падает ошибка. Ты читаешь трейсбек снизу вверх, цепляешься за знакомое слово, криво копируешь часть из терминала. Половину строки, с лишним пробелом. Открываешь Google.
Первая ссылка ведёт на StackOverflow. Вопрос 2014 года. Принятый ответ заминусован, а рабочий лежит третьим снизу. Сорок голосов, комментарий «this saved my life».
Ты его даже не копируешь, потому что случай всё равно другой. Но ты уже понял, в чём было дело.
Иногда уходишь на старый форум, на 23 страницу давно заброшенной темы. Последнее сообщение датировано 2015 годом. Аватарки битые, половина ссылок ведёт в никуда. И вдруг там, между «спасибо, помогло» и «у меня то же самое», сидит человек, который разобрал твою проблему по косточкам. Для себя. Не зная, что однажды его ответ спасёт кого-то ещё.
А иногда не находишь вообще ничего. Везде посмотрел, и пусто.
Чёрт с ним, спрошу сам.
Сидишь, формулируешь вопрос. Подбираешь слова. Прикладываешь минимальный пример, потому что иначе заминусуют. И сама эта формулировка наполовину чинит тебе мозги.
Жмёшь «отправить». Ждёшь. Обновляешь вкладку. И вот он, ответ от незнакомца, которому просто не всё равно.
Сейчас ты выделяешь трейсбек, не дочитав до конца, и пишешь: «почини».
И он чинит.
Работает. Тесты зелёные. Можно идти дальше.
Но где-то в этот момент из профессии исчезает важная часть ритуала. Та самая, где ты не просто получал ответ, а прожёвывал проблему. Злился, тупил, копался в чужих обсуждениях и постепенно начинал понимать, что вообще происходит.
Раньше ошибка была дверью. Сейчас она всё чаще становится всплывающим окном, которое хочется закрыть как можно быстрее.
И в этом есть что-то страшное.
Профессия программиста всегда держалась именно на привычке разбираться. На внутреннем упрямстве: «я хочу понять, почему оно сломалось».
А теперь у нас появился идеальный способ этого не делать.
Да, мы стали быстрее. Да, мы стали продуктивнее. Да, назад никто не пойдёт.
Но вместе с болью отладки мы выкидываем и кое что важное.
И, кажется, однажды мы проснёмся в мире, где код всё ещё пишется, ошибки всё ещё чинятся, продукты всё ещё выкатываются, но всё меньше людей действительно понимают, как это работает.
Вот это и пугает.
Не то, что ИИ заберёт работу.
А то, что он оставит нам работу, но постепенно заберёт профессию.
❤11👍6🔥4
Эпоха AI. Какой красивый pull-реквест!
Раньше внятное описание PR стоило дорого. Надо было сесть, вспомнить, что именно ты менял, отделить важное от неважного и сформулировать, зачем всё это было нужно. Тут подглядеть код, тут открыть задачу, тут свериться со спецификацией. Написать хорошее описание было отдельной работой.
Но ценность была не только в тексте. Пока писал описание, ты ещё раз проходил весь путь своего изменения. Иногда именно в этот момент находился забытый кейс, лишний код или странное решение. Описание PR было не просто документацией. Оно было следом от процесса мышления.
Теперь это умеет агент.
Весь контекст уже у него: задача, дифф, код, комментарии, спецификация. Достаточно одной команды — и появляется аккуратное описание PR. Список изменений, затронутые файлы, риски, план тестирования, краткое резюме. Обычно даже лучше, чем написал бы человек. И это объективно полезно.
Тестировщик быстрее понимает, что проверять. Фронтендер видит изменения в контракте. Разработчик через полгода может восстановить контекст задачи. Даже человек, далёкий от кода, способен разобраться, что произошло.
Работа стала прозрачнее. Хороших описаний стало больше. Коммуникация стала дешевле.
Но вместе с этим изменился смысл самого артефакта.
Раньше хорошее описание PR было косвенным сигналом того, что автор разобрался в изменении. Если человек мог внятно объяснить, что и зачем поменял, обычно это означало, что он хотя бы попытался выстроить у себя в голове целостную картину.
Теперь эта связь стала намного слабее. Идеальное описание больше не говорит, что автор всё понял. Оно говорит лишь о том, что кто-то сгенерировал идеальное описание.
Оно может быть точным. А может содержать ошибки. Может помочь ревьюеру. А может уверенно объяснять логику, которой никогда не существовало. Красивый текст по-прежнему выглядит убедительно, даже когда ошибается.
Но, пожалуй, это хорошая сделка. AI сделал хорошие описания PR массовыми. Выиграли тестирование, ревью, поддержка и будущие разработчики. Просто теперь описание показывает состояние репозитория. И имеет мало общего с мнением и пониманием автора.
Если тоже любите сравнивать, как разные модели справляются с кодом, документацией и ревью, можно попробовать Umnik AI. Там в одном месте собраны Claude, GPT, Gemini и другие модели без необходимости прыгать между десятком сервисов.
Раньше внятное описание PR стоило дорого. Надо было сесть, вспомнить, что именно ты менял, отделить важное от неважного и сформулировать, зачем всё это было нужно. Тут подглядеть код, тут открыть задачу, тут свериться со спецификацией. Написать хорошее описание было отдельной работой.
Но ценность была не только в тексте. Пока писал описание, ты ещё раз проходил весь путь своего изменения. Иногда именно в этот момент находился забытый кейс, лишний код или странное решение. Описание PR было не просто документацией. Оно было следом от процесса мышления.
Теперь это умеет агент.
Весь контекст уже у него: задача, дифф, код, комментарии, спецификация. Достаточно одной команды — и появляется аккуратное описание PR. Список изменений, затронутые файлы, риски, план тестирования, краткое резюме. Обычно даже лучше, чем написал бы человек. И это объективно полезно.
Тестировщик быстрее понимает, что проверять. Фронтендер видит изменения в контракте. Разработчик через полгода может восстановить контекст задачи. Даже человек, далёкий от кода, способен разобраться, что произошло.
Работа стала прозрачнее. Хороших описаний стало больше. Коммуникация стала дешевле.
Но вместе с этим изменился смысл самого артефакта.
Раньше хорошее описание PR было косвенным сигналом того, что автор разобрался в изменении. Если человек мог внятно объяснить, что и зачем поменял, обычно это означало, что он хотя бы попытался выстроить у себя в голове целостную картину.
Теперь эта связь стала намного слабее. Идеальное описание больше не говорит, что автор всё понял. Оно говорит лишь о том, что кто-то сгенерировал идеальное описание.
Оно может быть точным. А может содержать ошибки. Может помочь ревьюеру. А может уверенно объяснять логику, которой никогда не существовало. Красивый текст по-прежнему выглядит убедительно, даже когда ошибается.
Но, пожалуй, это хорошая сделка. AI сделал хорошие описания PR массовыми. Выиграли тестирование, ревью, поддержка и будущие разработчики. Просто теперь описание показывает состояние репозитория. И имеет мало общего с мнением и пониманием автора.
Если тоже любите сравнивать, как разные модели справляются с кодом, документацией и ревью, можно попробовать Umnik AI. Там в одном месте собраны Claude, GPT, Gemini и другие модели без необходимости прыгать между десятком сервисов.
1❤8🔥5💯5
🚨 КАСТРИРОВАЛИ МИФОСА?! Что Anthropic СКРЫВАЕТ от нас в подвалах Glasswing
Помните ту самую модель, про которую ходили слухи, что она сама находит 0-day и строит полноценные цепочки атак? Ту, что НЕ выпустили «по соображениям кибербезопасности» и раздали кучке избранных организаций под семью замками Project Glasswing?
Похоже, компания готовит её гражданскую версию - Claude Fable 5.
Что известно более-менее точно:
Mythos действительно никогда не выходил в паблик, официальная причина - кибербез-риски.
Доступ к нему - только через закрытую программу для «доверенных» (читай: тех, кому можно).
Что говорят в утечках:
Fable 5 заберёт у старшего брата длинный контекст, тяжёлую логику и длительную работу над задачами.
А вот всё «весёлое» - поиск уязвимостей, эксплойты, цепочки атак - обрежут на корню. Не «не хочет», а «физически не умеет».
Видимо Fable именно потому, что от Mythos осталась только сказка, а не миф 💀
Помните ту самую модель, про которую ходили слухи, что она сама находит 0-day и строит полноценные цепочки атак? Ту, что НЕ выпустили «по соображениям кибербезопасности» и раздали кучке избранных организаций под семью замками Project Glasswing?
Похоже, компания готовит её гражданскую версию - Claude Fable 5.
Что известно более-менее точно:
Mythos действительно никогда не выходил в паблик, официальная причина - кибербез-риски.
Доступ к нему - только через закрытую программу для «доверенных» (читай: тех, кому можно).
Что говорят в утечках:
Fable 5 заберёт у старшего брата длинный контекст, тяжёлую логику и длительную работу над задачами.
А вот всё «весёлое» - поиск уязвимостей, эксплойты, цепочки атак - обрежут на корню. Не «не хочет», а «физически не умеет».
Видимо Fable именно потому, что от Mythos осталась только сказка, а не миф 💀
👍5🔥3😁3
О как, только написал про слухи, а они взяли и выпустили Fable 5.
Кто слил мой пост в Антропик, признавайтесь?😂
Кто слил мой пост в Антропик, признавайтесь?
Please open Telegram to view this post
VIEW IN TELEGRAM
1😁10👍3