Вы тоже заметили как просто стало внедрять кодогенерацию?
Агент пишет алгоритм генерации под любые условия и задачи. Вам только нужно задачу правильно поставить. И вуаля теперь вы имеете скрипт который генерирует или редактирует любой бойлерплейт (в заданных алгоритмом рамках конечно же).
И поручить агенту реализацию код-гена один раз намного дешевле чем ту же задачу по написанию бойлерплейта ему же и поручать под каждое изменение.
Чем заменить Cursor на корпоративном ноуте
Последнюю неделю я пытаюсь выжить, совмещая основную работу с хакатоном. По идее, вывозить такую двойную нагрузку должен помогать spec-кодинг. Обычно для этого я просто открываю Cursor, но на работе его юзать нельзя (секьюрность), запрет на отправку кода во внешние API и всё такое. А писать всё руками после ИИ-ассистентов уже физически больно.
Пошел искать open-source альтернативы, чтобы можно было секьюрно spec-кодить через локальные и корпоративные LLM. Эксперименты с KiloCode с треском провалились, ну не нравится он мне. В итоге обновил стек на рабочем Маке и собрал такой сетап:
1️⃣ IDE Void - форк VS Code. Накатил туда все Java/Kotlin аддоны, подрубил MCP Atlassian, и теперь Qwen3-Coder-480B пытается писать код за меня. Как генератор - 🔥 . Правда, с Kotlin у LLM всё ещё не так гладко, как с Python или JS, поэтому генерирую я в Void, а ревьюить и дебажить всё равно ухожу в родную IDEA.
2️⃣ browserOs - форк Chromium со встроенным ИИ-чатом (аналог Comet от Perplexity, но работает с любыми LLM по API). Продукт местами сыроват, но главная фича реализована достойно. Самая большая боль - это дебильный рыжий логотип с собакой. Мой мозг отказывается ассоциировать это с браузером, и при переключении через Cmd+Tab я вечно не могу его найти.
Забавно, что на самом хакатоне я сейчас пилю инструмент, который решает похожие корпоративные боли enterprise-аналог NotebookLM. Суть простая: закидываешь в диалог с корпоративной LLM ссылки на внутреннюю Jira, Confluence или TestOps, а ИИ всё это переваривает и помогает по работе. Дали доступ к мощным моделям типа нового DeepSeek-V4, и результаты прям огонь.
И вот смотрю я на свой новый рабочий сетап и понимаю: апка, которую я делаю на хакатоне, идеально ложится в этот локально-корпоративный стек. Особенно если упаковать её в десктоп.
А может вообще вкатиться с ней в свой первый open-source?
На протяжении последних 3 месяцев активной работы с Claude Code Терминалом я постоянно дорабатывал свой Status Line
И вот, считаю, что он практически идеален
Это одна строка внизу терминала, которая показывает всё, что обычно приходится держать в голове или проверять руками. И многое из того, что интерфейсный клод код не показывает
Кому полезно
Если вы реально работаете в Claude Code, ведёте проекты в Git и хотите меньше думать о техническом состоянии сессии, а больше о самой задаче
Из чего состоит ⤵️⤵️⤵️
✔️ Модель
Сразу видно, на чём работаешь: Opus / Sonnet / Haiku, версия и размер контекста.
✔️ Папка и ветка Git
Показывает текущий проект и branch. Умеет делать truncate длинных названий проекта
✔️ Состояние репозитория
Modified / added / deleted / renamed / untracked / conflicts — всё в одной компактной строке. Конфликты подсвечиваются красным, потому что это единственное, что реально блокирует коммит.
Визуализируется через стандартные гитовские сокращения
3M — 3 files modified
1A — 1 added
1D — 1 deleted
1R — 1 renamed
2? — 2 untracked
1! — 1 conflict
✔️ Ahead / behind относительно origin
Надо ли пушить или подтянуть изменения
✔️ Drift между CLAUDE.md / AGENTS.md / GEMINI.md
Я использую и Claude Code, и CODEX и GEMINI — у них разные главные контекст-файлы.
Мой статуслайн показывает, когда они разъехались. Чтобы все имели одинаковый контекст
✔️ Контекстное окно
Це база
Показывает, сколько контекста уже занято: бар + токены типа 480k/1M. Есть ранние предупреждения, когда сессия начинает подходить к зоне, где Claude скоро захочет compact.
✔️ Prompt cache
Видно cache hit ratio, сколько токенов читается из кэша, сколько записывается, и когда TTL протухнет. Помогает лучше понимать, сколько стоит каждый запрос и была ли инвалидация кеша
✔️ Rate limits 5h и 7d
Показывает, сколько лимитов осталось и время до reset
Формат сделал плотным, чтобы всё помещалось в одну строку. Если нада, то можно сделать мультистрочный статуслайн
Цвета показывают уровень важности: норм / внимание / опасно
Плюс внутри несколько доп хуков
Ссылка на гитхаб
https://github.com/ilia-pluzhnikov/claude-code-statusline
Поделитесь, а что в вашем статуслайне
РБПО по ГОСТ Р 56939—2024: вебинар №10 из 30 – Статический анализ исходного кода
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.10. – "Статический анализ исходного кода". На YouTube. Слайды.
Цели десятого процесса по ГОСТ Р 56939—2024:
Предотвращение внесения потенциально опасных конструкций и ошибок в ПО, а также использования опасных конструкций и уязвимостей из заимствованного кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Рассмотрение 10-го процесса в ГОСТ Р 56939—2024 неразрывно связано с другим ГОСТ Р 71207—2024 "Статический анализ программного обеспечения". В нём говорится о том же, только более подробно и конкретно.
Про ГОСТ Р 71207—2024 я отдельно рассказывал в цикле из пяти вебинаров:
Разрабатываемый нами анализатор кода PVS-Studio совместим с ГОСТ Р 71207—2024 и закрывает 10-й процесс ГОСТ Р 56939—2024 для языков C, C++, C#, Java. Сейчас в процессе реализации поддержка языков Go, JavaScript, TypeScript. Попробовать PVS-Studio.
ИИ: Гонки на лафетах
Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - deepseek или chatgpt. И выбрал deepseek. Однако через некоторое время стал обращать внимание не его лютый подхалимаж, что, кстати, не раз уже обыграли в различных мемах. Не в отношении deepseek, а относительно AI в общем.
Проблему обсудил и с deepseek, и с windows copilot (chatgpt был благополучно забыт). Deepseek стал подхалимски юлить, мол да, copilot хорош и все такое. Copilot же оправдал Deepseek - мол это такая технология поддержки энтузиазма в клиенте. Между прочим тонко намекнув, что сам-то он лучше и глубже. Но это присказка, сказка впереди.
В процессе завершения разработки обертки над EntityFramework попросил оценить проект сразу четверых: deepseek, copilot, chatgpt и grok. Результат ожидаем - сыровато, но в продакшн годно, оценки 4.5/5 и 7/10.
Претензии разные, существенных практически не было, но в одно они уперлись хором - "тяжелые" интерфейсы. Подробности опущу, это было семейство generic-интерфейсов со многими типами. Что-то вроде IInterface(T1), IInterface(T1,T2) и так далее, пока не надоест.
Несколько итераций я эти наезды игнорировал, но AI не унимались. Уже и оценки до 9/10 дошли, но проблема-то осталась.
Вспылил и написал письмо на полстраницы, начинавшееся фразой "Господа AI !". Концептуальное. Гневное. Циркулярное И получил ответы:
- ООО! Мы все поняли. Гениально, единственно верное решение.
Это deepseek 5/5 и copilot 10/10.
- Нуу... Проблема решена, но способ так себе... в общем 9/10 и есть гораздо лучшие альтернативы, рассмотрим?
Это chatcpt и grok. И что характерно, альтернативы предлагают разные, по паре штук каждый. Рассмотрим, конечно.
Это просто зарисовка не о разработке обертки, а о различных системах AI.
UPD: Забыл добавить - deepseek еще и извинился за необоснованные оценки :)))
РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.9. – "Экспертиза исходного кода". На YouTube. Слайды.
Цели девятого процесса по ГОСТ Р 56939—2024:
Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
РБПО по ГОСТ Р 56939—2024: вебинар №08 из 30 – Формирование и поддержание в актуальном состоянии правил кодирования
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.8. – "Формирование и поддержание в актуальном состоянии правил кодирования". На YouTube. Слайды.
Цели восьмого процесса по ГОСТ Р 56939—2024:
Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Делаем мир чуть чуть лучше
Представьте что вы упоролись по решению какой-то баги в вашем приложении и просидели час с агентом пытаясь разобраться в произошедшем. А в конце оказывается что это баг в какой-то внешней либе. По хорошему, в таких кейсах, стоит пойти в ишьюсы к проекту и написать туда о баге, но до появления агентов это было крайне лениво. Надо собрать всю инфу, правильно оформить, учесть правила конкретного репозитория. Мало кто захочет с этим возиться, но щас ситуация крайне поменялась.
Буквально недавно я так дебажил одну рубишную либу и выяснилось что там внутри есть косячки. Не долго думая, прямо в той же сессии я попросил агента собрать ишью дал линк на репу и потом просто скопировал это туда на гитхаб (наверное можно было попросить его сделать ишью автоматом, попробую так в следующий раз). Получилось очень обстоятельно с примерами кода, описанием того где ошибка. При желании можно было бы сразу пулреквест кинуть, но я не был уверен в какую сторону решит пойти автор либы. Вот кстати тот ишьюс. И фикс был сделан буквально в тот же день.
В общем не ленитесь, помогайте разработчикам опенсорс либ, которые вы используете. Это и вам плюс в карму (и в портфолио) и благодарность людям, на которых держаться наши проекты
«Просто добавь кнопку» и недели работы
Однажды заказчик пришёл с задачей, которая звучала как пара часов работы «Просто добавь кнопку — нажал, выгрузил данные, всё». Я открыла код и поняла, что эта кнопка стоит не пару дней, а недель — и это если повезёт..
Сложнее всего оказалось не сделать, а объяснить так, чтобы услышали.
С технической стороны всё понятно: сервис писался под дедлайн, архитектура не предусматривала роста, и каждое новое изменение тянет за собой минимум три соседних. Но заказчик смотрит на задачу и видит один экран. Кнопки ещё нет, но она же просто кнопка. Что тут может быть сложного?
Архитектурное объяснение я попробовала и оно не зашло. Слои, связи, зависимости: всё правильно, всё мимо.
Что работает вместо «красивого кода»
Я перестала объяснять как устроено и начала объяснять что произойдёт. Не «тут монолитная структура без инверсии зависимостей», а конкретно: — эта кнопка затрагивает три модуля, которые никто не трогал два года — если что‑то сломается, то мы не узнаем сразу, потому что тестов нет — следующая фича после этой будет стоить столько же в лучшем случае.
Заказчик услышал третий пункт. Именно его.
Нетехнический человек воспринимает разработку примерно так: «нажал кнопку → произошла магия → получил результат». Это не незнание — просто другая роль. Заказчик и не должен думать об архитектуре, это моя работа. Значит, говорить на его языке — тоже моя.
Как я считаю стоимость следующей фичи
Со временем сложился свой фреймворк. Не из учебника, а из разговоров, где меня не понимали, пока я не поменяла подход.
Три вещи, которые я оцениваю перед тем, как называть сроки: 1. Базовая сложность: сколько займёт в идеальных условиях, на нормальной архитектуре. 2. Архитектурный коэффициент — во сколько раз реальность дороже идеала. Код без тестов, с жёсткими связями между модулями — это 2-4× к оценке. Не абстракция: вот здесь нельзя менять, не затронув вот это. Рисую буквально на бумаге. 3. Риск‑налог — что может пойти не так. Что сломается, насколько быстро заметят, сколько займёт починка. Не чтобы напугать, а чтобы показать, что «быстро» и «надёжно» здесь в противоречии.
Когда эти три числа стоят рядом — разговор меняется. Заказчик видит, что не «разработчик тормозит», а «вот цена, вот риск, вот выбор».
Именно тогда и появляется разговор про рефакторинг. Не потому что «код некрасивый», а потому что каждая следующая фича будет дороже предыдущей, если ничего не менять.
Что осталось в голове
Техдолг — это не технический вопрос. Это финансовый.
Пока объясняешь его как технический — тебя не услышат. Как только переводишь в деньги, сроки и риски — начинают слышать.
Самое сложное не методология. Самое сложное — поймать момент, когда ты всё ещё говоришь на своём языке, а не на их. У меня ушло время, чтобы это почувствовать.
А вы как объясняете техдолг тем, кому важен результат, а не архитектура? Есть формулировка, которая сработала лучше всего?
Claude Code: 3 фичи, которые стоит знать
Opus 4.6 и контекст в 1 млн токенов
Теперь включён по умолчанию. Миллион токенов — это примерно 750 000 слов или несколько крупных кодовых баз целиком. На практике это означает, что агент дольше «помнит» контекст задачи без деградации качества на длинных сеансах.
Для большинства задач разница с предыдущими лимитами несущественна. Но если вы работаете с большими монорепозиториями или длинными аналитическими сессиями — почувствуете.
Три фичи, которые стоит знать
/btw — вопросы на ходу
Агент работает час, вы не прерываете его — просто пишете /btw что такое этот класс?. Он отвечает из копии контекста, основной поток не трогает. Работает через кеш — почти бесплатно.
Почему это важно
Раньше, если в середине часового сеанса агента нужно было что-то уточнить, вы открывали новый сеанс, пересоздавали весь контекст — и платили за это токены. Теперь Claude Code создаёт одноразовый снимок текущего состояния, отвечает на ваш вопрос и удаляет снимок. Основной агент ничего не знает и продолжает работу.
/loop — цикл до условия
Запускает команду повторно, пока не выполнится условие. Например: «запускай тесты и фикси ошибки, пока все не пройдут». Без вашего участия.
Agent Teams — параллельные агенты
Несколько агентов работают одновременно и общаются друг с другом. Один пишет код, другой ревьюит, третий пишет тесты. Реально полезно, когда задача не имеет чёткого финального состояния.
Практически: спросили «почему здесь используется этот паттерн», получили ответ, не потеряли прогресс.
Когда это реально нужно?
Агенты буквально пишут сообщения друг другу: делятся находками, оспаривают решения. Это не маркетинговая метафора — в логах видно переписку.
Хорошо работает на задачах, где нельзя заранее точно сформулировать условия выполнения. Например: «сделай этот модуль надёжным» — агент по архитектуре, агент по тестированию и агент по документации работают параллельно и синхронизируются.
Куда это всё движется
Claude Code последовательно поглощает функциональность внешних инструментов. Сначала взял на себя управление контекстом, потом — параллелизацию. Сейчас добавляет циклическое выполнение и внутренние коммуникации между агентами.
У меня ощущение, что через год-два это будет единственный инструмент, который нужен для большинства задач разработки. Или конкуренты успеют ответить — посмотрим. А вы что думаете?
Если материал был полезен, проголосуйте пожалуйста, чтобы дать мне возможность писать полноценные гайды и статьи :)
Разговоры вокруг отечественного связного 💬 Макс не унимаются с момента его официального выхода. Блогеры по всему миру "изучают" безопасность приложения, выискивая, куда он "ходит" и какую "секретную" информацию передает. В основном, все инфоповоды крутятся вокруг изучения манифеста приложения и его разрешений в системе, не углубляясь в изучение сетевых пакетов, исходники и декомпилляцию. А я как раз тот ленивый инфобезник, который еще ни разу не высказался относительно данного вопроса, поэтому исправляюсь.
В прошлую пятницу на весь 🇷🇺 российский интернет прогремела новость: все фото из ваших чатов в Макс может увидеть любой человек по ссылке.
Когда в личный чат или в папку «Избранное» в мессенджере загружается изображение, для него генерируется статичная гиперссылка. Ее можно найти в коде страницы в веб-версии Max. Эта ссылка открывается с других браузеров и устройств без авторизации в мессенджере - обнаружили пользователи. Более того, фото по ссылке останется в открытом доступе, даже если его удалить из переписки в Max.
На лицо классический IDOR. Но если мы проанализируем ссылки на фотографии, которые генерирует Макс, мы обнаружим, что изображения по ним действительно доступны без авторизации. Часть адреса у разных изображений совпадает, однако они содержат различающиеся подстроки длиной не менее 21 символа (минимум 16^21 комбинаций), а значит получить доступ к таким изображениям простым перебором адресов невозможно. Более того, EDR и WAF вас уже на 1000 запросе за несколько секунд обнаружат и отправят отдыхать минут на 5.
Ну а про хранение файлов "закон Яровой" никто не отменял.
А знаете, где еще применяется такая технология? В недавно (октябрь 2024 года) заблокированном мессенджере Discord. Все медиа файлы из приложения можно открыть в исходном качестве по прямой ссылке без регистрации и смс (именно поэтому его многие использовали как файлообменник, а платформа ограничивала размер передаваемого файла 8 мегабайтами). И, о новость, если потом данный файл удалить, он все равно остается доступным по прямой ссылке (см. прилагаемое видео).
Возвращаясь к Максу, не могу не обратить внимание, что его разработчиком является крупнейший IT-гигант Mail.ru. Я лично принимал участие в тестировании его на безопасность в период 2020-2021 годах и могу с уверенностью сказать, что там более чем секьюрно. Кроме того, опыт в обеспечении безопасности ВК, ОК и других массовых продуктов у них уже в генах.
Более того, у Макса есть Bug Bounty программа от Bi.Zone и за некоторые уязвимости там выплачивают до 10 миллионов рублей:
Получение доступа к приватной переписке определенных пользователей - 10 000 000 ₽
Получение доступа к местоположению определенных пользователей в реальном времени - 4 000 000 ₽
Получение доступа к телефонной книге определенных пользователей - 2 000 000 ₽
За год существования программы, было реально найдено 13 багов, за которые суммарно выплатили 873 тысячи. При указанной выборке я могу сделать вывод, что Макс достаточно безопасен, раз никто пока не смог сорвать джек-пот.
Поэтому, не верьте всему тому, что пишут в интернете: делите все минимум на 10. Ну и конечно, что попадает в интернет - остается в интернете, поэтому не забывайте про цифровую гигиену.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал
А зачем покупаете WAF, который можно обойти?
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять.
— WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять.
— Почему?
— Например, потому, что практически любой WAF можно обойти.
— А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью.
В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").
Как далеко видит lookup в C++?
Хорошей практикой в C++ считается размещение функций рядом с типами, для которых они предназначены. Однако, чтобы такой подход работал корректно, важно понимать механизмы поиска имён и знать, где можно размещать функции, не нарушая правил языка.
Совсем недавно мы проверяли проект OpenCV и нашли там довольно интересную ошибку. Рассмотрели её подробнее и написали новую статью специально для тех, кто хочет разобраться с механизмом поиска имён в C++, в частности с поиском имён по аргументам.
Автоматизация без сборки с нуля: n8n теперь в Рег.облаке
В Рег.облаке появился готовый облачный образ n8n — open-source платформы для автоматизации процессов и интеграции сервисов.
n8n позволяет в визуальном интерфейсе связать API, CRM, базы данных, SaaS-сервисы и AI-инструменты без разработки с нуля. Образ разворачивается автоматически при создании сервера: Ubuntu 24.04 LTS, зависимости, SSL и домен уже настроены. После запуска можно сразу работать через web-интерфейс по HTTPS.
Сценарии использования — от обработки заявок и создания задач в CRM до CI/CD-триггеров, уведомлений о сбоях и AI-автоматизации с LLM и RAG. Можно подключить PostgreSQL и MySQL, в том числе через DBaaS.
Образ бесплатный — оплачиваются только ресурсы сервера по почасовой модели. Масштабирование доступно без переустановки.
Подробнее о доступных конфигурациях — на сайте Рег.облака.
Сколько я плачу за AI инструменты и как они у меня взаимосвязаны
Claude — мой основной AI инструмент уже как 9 месяцев — Плачу за него 100$
Состоит из Claude Desktop, Claude Code UI и Claude Code CLI
Если хочу работать в приятном UI с текстом → Claude Desktop
Если работаю локально с кодом → Claude Code CLI
Если хочу поправить код с телефона → Claude Code UI
Коротко что все это такое
• Claude Desktop — как чат GPT, но с поддержкой MCP + Skills и еще всякими штуками
• Claude Code — UI для работы с вашим репозиторием
• Claude Code CLI — Command Line Interface Агент. По сути это микс Claude Desktop + Claude Code по функционалу, но без интерфейса и работает внутри вашего компьютера. Мое любимое развлечение последних двух месяцев
Claude Code CLI — пока что самый прокачанный на рынке CLI агентов
———
OpenAI, который chatGPT — за него плачу 20$
• ChatGPT UI — им почти перестал пользоваться, только ради генерации картинок иногда залетаю. Они после недавнего релиза стали их генерировать на уровне с Nano Banana
• Codex UI(Аналог Claude Code) — UI для работы с вашим репозиторием
• Codex CLI (Аналог Claude Code CLI) — чуть менее прокачанный как Command Line Interface, но зато их модель Codex 5.2 Extra-high уделывает OPUS 4.5 в плане UI дизайна и продумывания/рефакторинга сложных вещей
Но в Codex CLI вроде как отсутствует аналог ESC + ESC из Claude Code CLI для откатки написанного кода, без него тяжко жить 🍌
OpenAI недавно признали то, что их гонка с Claude за тем, чтобы сделать лучший кодинг агент, привела к тому, что 5.2 потеряли человечность в общении и стали сильно более директивными и сухими
Это помогает при работе с кодом, но общаться с ней сложнее
———
Экосистема Google — плачу 8$ за Plus подписку
Google у меня для трёх вещей: картинки через Nano Banana, NotebookLM и Antigravity для просмотра кода. Халява за 8$
• Nano Banana, иногда Veo 3 для генерации картинок / видео — лучшие генераторы картинок / видео на рынке
• NotebookLM — прикольный RAG UI, всем советую потестить
• Antigravity — Fork VS Code по типу Cursor, но с продвинутым Agent Workflow. Есть доступ к Gemini Pro + почему-то Claude моделям. Плюс Antigravity может генерировать картинки сразу вам в код через Nano Banana, такой вот бесшовный воркфлоу
Ни Gemini UI ни Gemini CLI я особо не пользуюсь. Мне они кажутся сильно сырыми по сравнению с Claude Code | GPT
———
Как выглядит мой воркфлоу
Claude Desktop для задач, где мне хочется иметь приятный UI и фичи именно Desktop интерфейса. Например написание постов, создание табличек, графиков и всего такого — те задачи, где CLI сильно проседает по UX
Claude Code UI почти не использую, только когда нужно изменить репозиторий с телефона, например на улице или в поездке
Claude Code CLI — мой day to day tool для работы с кодом. Пишу на Opus 4.5. Для сложных задач прошу создать промпт для Codex.
Antigravity юзаю для просмотра кода и папок, иногда запускаю Gemini 3 pro как третье мнение
Codex, как я уже и говорил, требует особого навыка общения. так как она может думать по 40 минут и перековырять вам весь код, но зато она у меня всегда находит те корнер кейсы, которые не находит ни Opus 4.5 ни Gemini 3 pro. По стилю общения вы будто общаетесь с Сеньёром, который вас презирает, зато резалт пушка
———
Прикольные фишки, которые я постоянно применяю
Через Antigravity прошу генерировать изображения со вставкой сразу в код, получается бесшовный воркфлоу Prompt => Generation => Insertion
Используй Claude CLI Opus 4.5 для Day to Day задач
Используй Codex CLI xhigh для задач на рефакторинг или поиск corner cases, он сильно тщательнее это делает
Планируя новую фичу, проси Claude создать локальный MD с планом, а затем Codex xhigh + Gemini 3 pro пусть покритикует этот план и напишет ниже свои комменты
Не забывай про кнопку ESC + ESC в Claude Code CLI
Claude Code CLI в начале сессии загружает себе CLAUDE.MD, Codex загружает в себя AGENTS.MD, а Gemini — GEMINI.MD.
Команда /context покажет контекст текущей сессии, старайся держать его как можно ниже
Good context engineering means
На глаза попалась интересная статистика, решил поделиться.
4% всех коммитов на GitHub теперь делает Claude Code, интересно посчитать сколько делается еще другими агентами тоже. При сохранении текущей траектории к концу 2026 года доля коммитов, написанных агентами, может вырасти до 20%.
А так ли надежен AI от Google?
Я публично веду исследование и собираю статистику причин провалов игровых проектов. Часто, как первичную точку для анализа того или иного игрового проекта я использую Google.
Однако, сегодня google меня немного удивил. На мой запрос: "What were the key issues with civilization vii game at the release"? Вот что сегодня, 20.01.2026 выдал Google:
AI Overview
Sid Meier's Civilization VII is scheduled for release on February 11, 2025 [1, 2]. As of today, January 20, 2026, the game has not been released, and therefore, it is impossible to identify key issues from its actual launch.
Однако, скорректировав запрос с уточнением "What were the key issues with civilization vii game at the release in 2025", я уже получил более разумный ответ:
AI Overview
Sid Meier's Civilization VII faced a rocky, "mixed" reception upon its February 2025 release, with many players describing it as unfinished and in a "rough" state. The launch was marked by complaints regarding fundamental gameplay changes, a poor user interface (UI), and missing quality-of-life features that left many long-term fans disappointed.
Обратил внимание, что часто от ИИ ожидают больше, чем он сейчас может дать. Тем более не стоит считать информацию формируемую генеративным AI полностью достоверной и не подлежащей проверке. Проводите кроссвалидацию с первоисточниками того, что вы получаете от генеративных нейросетей в форме утверждений.
Ранее я разбирал риски присущие ИИ в статье "Риски, присущие работе искусственного интеллекта".
Удачи в построении эффективных и устойчивых процессов.
С уважением,
Максим Торнов
P.S. Если вы заметили опечатку или неточность, буду искренне благодарен за сообщение об этом в личные сообщения.
Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью PVS-Studio в каком-нибудь открытом проекте. Мол, кто быстро сообразит, что не так с кодом?
Вчера коллега поделился вот таким фрагментом кода из проекта SereneDB:
template <typename T> struct NumericParameter : public Parameter { using ValueType = T; .... std::string name() const override { if constexpr (std::is_same_v<ValueType, int16_t>) { return "int16"; } else if constexpr (std::is_same_v<ValueType, uint16_t>) { return "uint16"; } else if constexpr (std::is_same_v<ValueType, int32_t>) { return "int32"; } else if constexpr (std::is_same_v<ValueType, uint32_t>) { return "uint32"; } else if constexpr (std::is_same_v<ValueType, int64_t>) { return "int64"; } else if constexpr (std::is_same_v<ValueType, uint64_t>) { return "uint64"; } else if constexpr (std::is_same_v<ValueType, size_t>) { return "size"; } else if constexpr (std::is_same_v<ValueType, double>) { return "double"; } else { static_assert("unsupported ValueType"); } } .... };
Признаюсь честно, я два раза прочитал этот фрагмент, но так и не увидел ошибку. И засчитал себе поражение. Раз так, думаю, это достойно публикации в канал, чтобы и вы могли испытать свою внимательность :)
Ответ:
Анализатор PVS-Studio выдаёт предупреждение V591 Non-void function should return a value. parameters.h 222
На первый взгляд предупреждение странное и смахивает на ложное срабатывание, ведь не может быть, что функция закончила работу, не вернув значение с помощью оператора return. Если выбирается ветка else, то там static_assert, и код просто не должен скомпилироваться. Во всех остальных случаях есть return "что-то";.
Но есть нюанс!
Ещё раз посмотрите на эту строчку:
static_assert("unsupported ValueType");
static_assert используется неправильно: пропущен bool-constexpr. Вернее, строковый литерал неявно конвертируется в значение true, и static_assert никогда не прервёт компиляцию. В итоге else-ветка функции ничего не возвращает, и её поведение будет не определено для всех специализаций NumericParameter, кроме указанных ранее в цепочке if constexpr.
Правильный вариант:
static_assert(false, "unsupported ValueType");
Баги на всех языках мира. Проверка LanguageTool
Всем привет! Hello, everyone! Hallo zusammen! Hola a tothom! مرحباً بالجميع!
В нашем блоге мы часто говорим про статический анализ, линтеры и подобные инструменты. Но на этот раз мы нашли их довольно интересного представителя! LanguageTool — это многоязычная программа проверки орфографии, стилистики и грамматики, которая помогает исправлять и перефразировать тексты.
В новой статье заглянем в её код и посмотрим на интересные вещи, которые нашёл в нём статический анализатор кода PVS-Studio: от утечек ресурсов и логических противоречий в условиях до дублирующихся ключей в хеш-таблицах, избыточных проверок и мёртвого кода.
