Все потоки

Как все так ловко ИИ пользуются... Обзоры кода делают...

Не знаю, то ли я туповат, то ли невезучий, то ли кругом сказочники. Пытаюсь исследовать, какие новые интересные виды ошибок может находить ИИ в С++ коде, о которых не знает PVS-Studio. Claude Opus то нормально мне про интересные баги рассказывает, то на ровном месте с ума сходит.

Даю файл на вход, а он тревожно:

В присланном файле есть места, где содержимое обрезано/повреждено вставкой </context>, поэтому их я не рассматриваю как «баги кода» — это артефакты форматирования. Разберу реальные логические ошибки.

Шо? Какой context? Там максимум — это #include "context.hxx". Ну ладно, давай ошибки посмотрим.

Так, парочка сообщений по делу. Например, найден лишний аргумент при использовании функции форматирования.

addErrorMessage(&sciErr, API_ERROR_CREATE_ZDOUBLE_IN_NAMED_LIST,
    _("%s: Unable to create list item #%d in Scilab memory"),
    "createComplexZMatrixOfDoubleInNamedList", _iItemPos + 1, _pstName);

В строке форматирования два спецификатора %s и %d, а передаются три аргумента: funcName, _iItemPos+1, _pstName. Да, это баг. Про подобные паттерны PVS-Studio уже знает, хотя, возможно, нужно подсказать, что addErrorMessage — это printf-подобная функция. В целом, тут неинтересно, идём дальше.

Ооо, и тут начинается...

checkListItemPosition — неправильное сравнение границы:

// check a valid item
if (_iItemPos > iItem)
{
    addErrorMessage(...);
    return sciErr;
}

Здесь проверка «позиция валидна» использует >, хотя позиции 1-based, а iItem — количество элементов. Это выглядит как граничный дефект, но по сути _iItemPos == iItem допустимо, _iItemPos > iItem — ошибка. Это в порядке — правильная граница. Не баг. (Указываю, чтобы было понятно, что я это проверил.)

Так баг или не баг? Я три раза прочитал текст и посмотрел функцию с кодом. В итоге я не только не понимаю, есть ли здесь ошибка, но и не понимаю, что Claude пытается мне сказать.

Дальше ещё хуже шарики за ролики зашли.

Баг 5 (реальный): утечка в readCommonMatrixOfPolyInNamedList и др. — нет, это API отдаёт указатели наружу. Не баг.

Это всё описание пятого бага, больше ничего нет. Комментировать — только портить.

Я не понимаю, как на всём этом можно строить хоть сколько-то надёжные процессы автоматических обзоров кода, про которые в последнее время из разных утюгов вещают.

На сегодня мне ИИ достаточно. Пойду лучше пройдусь по парку, пока погода хорошая.

Открытый проект CAPTCHA Solver — CloakBrowser + 2Captcha/CapSolver имитирует поведение человека и проходит почти все проверки на ботов. Инструмент умеет:

• решать на раз‑два более 30 видов капчи, имитирует поведение человека, чтобы обойти любые ограничения.

• ставится локально, в сервисе не надо регистрироваться и устанавливать дополнительное ПО..

Fable 5 вернули в Claude Code. Как не сгенерировать себе техдолг

Fable 5 снова доступен в Claude, и это хороший повод вернуться к более практичному вопросу: что именно делать разработчику с Claude Code, кроме генерации отдельных кусков кода.

В реальных задачах сложность обычно не в том, чтобы получить от модели отдельную функцию или заготовку сервиса. Гораздо важнее — превратить это в рабочий продукт: удерживать контекст, заранее задавать ограничения, проверять результат и не собрать после первого демо проект, который страшно поддерживать.

21 июля в 20:00 на бесплатном уроке разберём, как использовать Claude Code в разработке ИИ-приложений: от Telegram-ботов и агентов до внутренних сервисов, API и автоматизаций. Отдельно поговорим о работе с большими задачами — как дробить их на этапы, вести разработку итерациями, дорабатывать код и находить ошибки. Присоединяйтесь.

Все июльские разборы по ИИ, разработке, архитектуре и инфраструктуре собрали в дайджесте мероприятий.

Избиратели против ботов

Economist вышел с обложкой на статью про возрастающее требование избирателей затормозить/запретить ИИ. Это волна только разгоняется, по сути луддиты 21 века, но так как политики часто используют подобные недовольства масс населения, то тему точно будут раскачивать.

Конкретно это выражается уже в начале запретов строить дата‑центры; справедливости ради надо сказать, что отдельные дата‑центры действительно уже портят жизнь конкретным городам Америки.

Уже обсуждаются прочие законы: прозрачность и маркировка ИИ‑контента, запреты и ограничения deepfakes, защита рабочих мест и «разделение выгод» и т. д.

Я думаю, все, кто хочет разделения выгод, получат себя в human in the loop 😀

Сравнение Code Fable и Codex по ходу работы над одним и тем же проектом

Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.

Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.

Что сказать про впечатления? - Ощущение вот того самого вайб кодинга, о котором говорил Карпаты. Говоришь ему что делать и он делает. Технических ошибок просто нет, от слова совсем. Есть ошибки архитектурные, но не существенные, исправляются одной-двумя итерациями.

И кстати, получилось сравнить с Codex'ом, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.

Но вот вокруг кода хуже: болтливые они оба, но у Codex больше какой-то разболтанности, разбрасывания в стороны. Особенно это видно на написании документации, пишет незначительные детали, теряет главное. И слабее держит инструкции.

Code в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.

Единственное, что может я так натаскал Code. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.

И напоследок обнаружил в Code очень полезную функцию оценки загруженности контекстного окна.

Может она уже давно там была, о ней вроде писали, но что-то казалось, что это в CLI. А теперь оказывается её можно использовать и в декстопной версии. Думаю и другим пользователям это тоже пригодится.

Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.

Для этого в чате Code, в поле ввода достаточно ввести слэш команду - /context

Прикрепляю скриншот как это выглядит вживую

И ещё такое впечатление, что Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.

Так что, удачи всем с проектами на этой бурной трудовой неделе!))

Тамагочи, но вместо котика – команда разработчиков. И она выгорает, пока вы читаете этот пост

Помните тамагочи? Пищащий брелок, который тихо умирал, если про него забыть на выходных.

Мы сделали такой же. Только вместо котика у вас разработчик и команда. Вместо «покормить» – 1-on-1, код-ревью, менторство и релизы. Забьете на пару дней – вернетесь к просевшему доверию и зреющему конфликту.

И живет это все прямо в терминале на сайте. Без установки, без регистрации, без «оставьте почту».

Что это

team – симулятор тимлида в консольном режиме нашего сообщества. Не модалка с кнопками: вы открываете фейковый (но честно рабочий) терминал и печатаете команды.

team new – и у вас есть напарник-стажер и живая команда.

Дальше вы его растите от стажера до CTO.

Цель проста на словах: дорастить человека до уровня «тимлид» и выкатить пять релизов, не развалив команду по дороге.

Почему это тамагочи, а не просто игра

Вот тут начинается интересное. Состояние живет в localStorage и распадается в реальном времени.

Пропали на день – доверие просело, конфликт подрос, напарник задремал. Пропали надолго – рискуете вернуться к game over: команда либо выгорела, либо развалилась от конфликтов.

Это питомец, который ждет. И портится без вас.

Дилеммы из реальных споров

Периодически прилетает инцидент. Звезда принесла оффер +40% и мнется. Прод упал в пятницу в 18:00. Двое неделю спорят: монолит против микросервисов. Выбираете вариант – получаете последствия в метриках и в журнале команды.

И часть инцидентов подтягивается из живого бэклога вопросов нашего сообщества. То есть в игру попадают дилеммы, которые реально обсуждали практикующие тимлиды, а не выдуманные кейсы из учебника.

Как сыграть

Никакой установки. Открываете терминал и печатаете team:

https://teamleads.kz/shell/

team help покажет правила, team new начнет игру, team share соберет ссылку-результат, чтобы похвастаться (или пожаловаться) в чате.

Растите аккуратно. Ваш разработчик, кажется, уже начал скучать.

РБПО по ГОСТ Р 56939—2024: вебинар №29 из 30 — Системы с конструктивной информационной безопасностью (ГОСТ Р 72118—2025)

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Системы с конструктивной информационной безопасностью". На YouTube. Слайды.

С помощью приглашённого эксперта Екатерины Рудиной, аналитиком департамента перспективных технологий "Лаборатории Касперского", мы разобрались, в чём сходство и различие таких систем с безопасным ПО, как соотносятся создание систем с КИБ и разработка безопасного ПО, чем полезен в работе специалистов по ИБ новый ГОСТ Р 72118—2025 "Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки".

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Вышла бесплатная книга к курсу «SQL Введение»

Всем привет!

Недавно я публиковал здесь бесплатный курс «SQL Введение» на платформе Stepik. За это время курс уже начали проходить более 400 студентов.

В продолжение курса я подготовил ещё один бесплатный материал — книгу, которая поможет изучать SQL ещё удобнее.

Бесплатный курс: https://stepik.org/a/290855

Зачем появилась книга

Во время обучения многим удобно иметь материал не только в формате уроков, но и в виде единого пособия, к которому можно быстро вернуться в любой момент.

Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.

Что представляет собой книга

Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.

Её можно использовать как:

• офлайн-версию курса для повторения материала;

• удобный конспект при выполнении практических заданий;

• справочник для быстрого повторения основных конструкций SQL.

Если вы уже проходите курс, книга поможет быстрее находить нужную информацию и возвращаться к темам, которые хочется повторить.

Для кого она будет полезна

Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:

• студентов IT-специальностей;

• начинающих разработчиков;

• будущих аналитиков данных;

• тестировщиков;

• всех, кто хочет разобраться в основах работы с реляционными базами данных.

Бесплатный доступ

Книга распространяется бесплатно.

Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.

Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.

https://github.com/Awilum/sql-introduction

Чтобы скачать последнюю актуальную версию, перейдите в раздел Releases, где всегда доступен самый свежий выпуск книги. 

https://github.com/Awilum/sql-introduction/releases

Буду рад вашим отзывам, предложениям и замечаниям как по курсу, так и по книге. Надеюсь, этот дополнительный материал сделает изучение SQL ещё более удобным и понятным.

Как выживают разработчики Госуслуг на защите квартального плана

У каждого, кто работает с госсектором, есть обязательная процедура — защита квартального плана. Что там происходит на самом деле и почему даже сильные команды «сыпятся» под вопросами заказчика?

Разбирались вместе с заместителем технического директора РТЛабс Виктором Редровом на OKR Russia

В докладе о том:

• Почему защита — это диалог, а не отчёт (и как к этому подготовиться)

• Типичные ошибки, которые превращают встречу в «допрос»

• Конкретные приёмы для сохранения контроля в любой ситуации

👉 Презентация и запись доступны по ссылке

В дополнение к посту по albu-mcp

В доке Albumentations появился отдельный раздел про мой AlbumentationsX MCP - https://albumentations.ai/docs/integrations/mcp/

Теперь есть официальный integration guide, где показано, как ты можешь подключить MCP-сервер к AI-assistant’у и использовать его для нормального HITL workflow вокруг CV-аугментаций: подобрать pipeline, провалидировать его, отрендерить локальные previews, сравнить baseline и candidate, дать feedback вроде too_noisy:high и экспортировать финальный pipeline.

Приятно видеть, что проект стал частью экосистемной документации Albumentations. 🙂

AlbumentationsX MCP это конечно же не замена Python API, а assistant-facing review layer для тех случаев, когда ты хочешь быстрее и безопаснее работать с augmentation pipelines.

SimpleOne подтвердила совместимость с РЕД ОС

SimpleOne подтвердила совместимость своей платформы с РЕД ОС. Для заказчиков это значит, что запуск проектов в импортонезависимой ИТ-среде становится проще и предсказуемее.

Подтвержденная совместимость помогает:

• сократить барьеры на этапе архитектурных согласований

• упростить прохождение аудитов безопасности

• быстрее запускать проекты по переходу на российское ПО

РЕД ОС широко используют в корпоративной и государственной инфраструктуре. По данным разработчика, систему уже применяют 12 000 компаний и государственных организаций, а общее количество инсталляций превысило 2 млн.

Подробнее на сайте

Представлен открытый проект Ghostprovider — терминальный инструмент для быстрого запуска GitHub‑проектов у себя на localhost.

Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.

Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.

Автоматизировать, нельзя делать вручную

С помощью ИИ можно автоматизировать почти что угодно, и именно поэтому многим сложно встроить его в повседневную работу. Непонятно, с чего начинать и какие процессы действительно стоит отдавать ИИ. В итоге идеи часто остаются на уровне «надо бы попробовать», но до реального использования так и не доходят.

Константин, специалист по ИИ в Naumen, рассказал, какие задачи стоит автоматизировать в первую очередь и по каким признакам понять, что процесс действительно подходит для ИИ.

Проверьте процесс по трем критериям

Перед тем как автоматизировать любую задачу, ответьте на три вопроса.

1. Боль. Насколько процесс раздражает, отнимает время или приводит к ошибкам?

2. Частота. Как часто вы его выполняете: каждый день, каждую неделю или раз в месяц?

3. Стоимость автоматизации. Есть ли понятные правила, по которым выполняется задача, или каждый делает ее по-своему?

Идеальный процесс для автоматизации выглядит так: часто повторяется, на него уходит много времени и это раздражает, выполняется по понятным правилам.

В первую очередь автоматизируйте работу с информацией

Практически любая задача, связанная с обработкой информации, — хороший кандидат для автоматизации.

Например:

• Парсинг сайтов конкурентов, изучение технической документации, сбор данных из отчетов — в 90% случаев это можно доверить ИИ. Человек подключается только для валидации результата: проверить, не упущено ли что‑то важное, адекватен ли вывод.

• Изучение документации — нет смысла читать 50 страниц документации вручную, когда ассистент справляется за минуту и выдает выжимку.

• Любая работа с форматированием данных — привести таблицу к единому виду, объединить информацию из нескольких документов, удалить дубли или преобразовать данные в нужный формат.

Следующий шаг — база знаний команды

Во многих командах нужная информация существует, но хранится сразу в нескольких местах: в чатах, документах, личных заметках, папках или переписках.

Если собрать материалы по конкретным рабочим сценариям в единую базу знаний, можно создать ассистента, который:

• отвечает на вопросы;

• находит нужные фрагменты;

• помогает новым сотрудникам быстрее разобраться в теме;

• снижает количество однотипных вопросов внутри команды.

Важно, чтобы в базе была только полезная и актуальная информация. Чем больше шума и лишних документов, тем выше вероятность ошибок и неточных ответов.

Например, вместо поиска по нескольким чатам можно просто спросить ассистента: «Как у нас проходит релиз продукта?» или «Какие требования сейчас действуют для этой интеграции?».

А еще ИИ помогает командам лучше понимать друг друга. У каждой команды постепенно появляется свой язык: внутренние термины, сокращения, привычные формулировки. То, что разработчики считают очевидным, может быть непонятно продажам или менеджерам. Ассистент помогает быстрее переводить этот контекст между командами и снижает количество недопониманий в коммуникации.

Например, менеджер по продажам может попросить: «Объясни простыми словами, как работает эта функция, чтобы я мог рассказать о ней заказчику без технических терминов».

Создать такого ассистента сегодня можно несколькими способами

• Для команды

Мы, например, создали платформу на базе Open WebUI. Любой сотрудник может создать ассистента, загрузить в него документы и открыть доступ коллегам. Ассистент помогает быстро находить информацию по вебинарам и рабочим материалам.

• Для общей базы знаний

Можно подключить Claude Code к внешним репозиториям и использовать их как общую базу знаний команды. В таком сценарии ассистент получает доступ к рабочим материалам, заметкам и документам, которыми пользуются сразу несколько сотрудников. 

• Для личной работы

Можно собрать локальную базу знаний для себя: все рабочие материалы хранятся прямо на компьютере и никуда не передаются.

Главное — не пытаться автоматизировать все сразу. Найдите процесс, который часто повторяется, действительно мешает работать и выполняется по понятным правилам. Именно он обычно дает самый заметный результат.

Прилетело и в очередной раз и резануло по живому...

Системность - это ... (продолжите фразу)

Системность - это модное словечко из лексикона "эффективных менеджеров", которое скорее вводит в заблуждение, чем отражает суть.

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

Реже - наличие системного подхода, где любая ситуация воспринимается, как комплекс взаимосвязанных элементов и чтобы добиться желаемого результата следует рассмотреть все составляющие системы и надсистемы с прогнозом их поведения в зависимости от разных вариантов воздействия.

Вот только системный подход - это системный подход, а системность - это признак системы. И как признак системы это ...

НЕ ПРО ПОРЯДОК!

Системы вообще никакого отношения к порядку не имеют - любая система стремится к хаосу (тут умное слово - энтропия).

И только лишь работа с системой предполагает упорядочивание элементов и связей - чтобы во всём этом разобраться.

Как разграничить задачи ИИ и человека в маркетинговой стратегии: кейс перестройки процесса в digital-агентстве

По Stanford AI Index Report 2026, точность frontier-моделей на тестах устойчивости расходится от 14% до 90% в зависимости от задачи. Одна модель на близких запросах даёт противоположные результаты.

McKinsey State of AI 2025: 88% организаций используют ИИ, но только 6% получают более 5% EBIT. Разрыв не в доступе к моделям — в перестройке процессов вокруг них.

Ниже — кейс маркетингового агентства: что автоматизировали зря, что оставили за человеком, как измеримо изменились показатели.

Первая попытка: автоматизация всего подряд

Гипотеза: если LLM умеет анализировать данные и генерировать варианты — отдать всё, стратег подключается на финальной проверке.

Через три месяца:

Стратегия для салона в Праге и в Минске
отличались ТОЛЬКО названием города.

Модель не учла:
- Прага: выбор через локальные форумы
- Минск: выбор через Google Maps rating

Клиент: «Это не про мой город. Это про
абстрактный салон в абстрактном городе».

Проблема структурная. LLM генерирует на паттернах из обучающей выборки. Локальные микропаттерны конкретного рынка представлены недостаточно. Fine-tuning смягчает — не решает.

Аудит: 70/30

70% времени стратега = сбор данных
- парсинг отзывов конкурентов
- обработка расшифровок кастдевов
- сегментация UGC
→ LLM делает быстрее и без 
  потери качества к концу дня

30% времени = принятие решений
- выбор позиционирования
- культурная адаптация
- защита стратегии перед клиентом
→ требует опыта, которого 
  у модели нет

Автоматизировать можно сбор данных. Делегировать модели стратегическое решение — нельзя.

Распределение по этапам

Исследование ЦА:       80% ИИ / 20% стратег
Конкурентная разведка: 85% ИИ / 15% стратег
Позиционирование:      30% ИИ / 70% стратег
Каналы и бюджет:       60% ИИ / 40% стратег
Защита стратегии:      10% ИИ / 90% стратег

Чем ближе задача к решению — тем меньше доля ИИ.

Кейс где новая пропорция сработала

B2B-производитель стройматериалов, выход на новый рынок, 43 конкурента.

Ручной анализ: неделя работы стратега
С ИИ: один вечер обработки

Собрали: цены, отзывы, объявления,
упоминания на форумах.
Результат: таблица 43 × 12 параметров.

Утром стратег нашёл закономерность: в негативных отзывах 8 из 43 конкурентов повторялась жалоба на скорость расчёта стоимости доставки.

Позиционирование: «Стоимость доставки в вашем городе — за 15 минут».

За 3 месяца: 227 B2B-лидов, CPL снижен с $50 до $20.

Модель не сгенерировала это решение. Она структурировала данные так, чтобы паттерн стал видимым. Интерпретация «жалоба на скорость расчёта = незакрытая ниша» — работа человека.

Три вывода

1. Frontier-модели (GPT-5.5, Claude Opus 4, DeepSeek R2) обновляются каждые 2–4 месяца. Ценность — в цепочке промптов и обученных проектах под конкретный домен.

2. Верификация — часть процесса, не опция. При разбросе точности 14–90% каждый output проверяется вручную.

3. ИИ усиливает доменную экспертизу, не заменяет. LLM работает как инструмент в руках эксперта.

По McKinsey, компании с полностью перестроенными процессами получают в 2,5 раза более высокий рост выручки. Ключевое — «полностью перестроенные», а не «купили подписку».

Какая пропорция автоматизации сложилась в вашей команде и в каких задачах модели показали устойчивые ошибки после дообучения?

А вам знакомо ощущение, когда тревога стала постоянным спутником жизни, когда привык к ней и просто перестаешь замечать?

У меня так было, причем очень долго. Последние лет пять тревожность была моей личной проблемой, с которой я пыталась как-то жить. Держала всё в голове, героически молчала, ночью раскручивала сценарии катастроф, гуглила симптомы, пережёвывала рабочие ситуации и делала вид, что всё нормально. Классика жанра: прод горит, но мы уверенно называем это «просто период такой».

В новой статье я попробовала посмотреть на тревожность через инженерную оптику: как на систему, где есть алерты, инциденты, мониторинг, ранбуки, команда поддержки, план отката и право не держать стопроцентный аптайм каждый день.

Но эта статья больше про мой личный опыт. И мне очень интересно, а как вы справляетесь с тревожностью? Что вам реально помогает, а что оказалось бесполезным советом?

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

https://habr.com/ru/companies/alfa/articles/1054022/

Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.

🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?

19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.

📐 Проверенная методология FPF + TDD в основе каждого блока.

🔗 Подробное описание: https://debugskills.ru/content?article=labs-ai-orchestration
Готовы спроектировать свою первую AI-экосистему? Приходите 19 июля! 🚀

Сравнение Claude Code Fable и Codex Open AI по ходу работы над одним и тем же проектом

Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Claude Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.

Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.

Что сказать про впечатления? - Ощущение вот того самого вайб кодинга, о котором говорил Карпаты. Говоришь модели что делать и она делает. Технических ошибок просто нет, от слова совсем. Есть ошибки архитектурные, но не существенные, исправляются одной-двумя итерациями.

И кстати, получилось сравнить с Codex'ом от Open AI, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.

Но вот вокруг кода хуже: болтливые они оба, но у Codex больше какой-то разболтанности, разбрасывания в стороны. Особенно это видно на написании документации, пишет незначительные детали, теряет главное. И слабее держит инструкции.

Claude Code Fable в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.

Единственное, что может я так натаскал Claude. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.

И напоследок обнаружил в Claude очень полезную функцию оценки загруженности контекстного окна.

Может она уже давно там была, о ней вроде писали, но что-то казалось, что это в CLI. А теперь оказывается её можно использовать и в декстопной версии. Думаю и другим пользователям это тоже пригодится.

Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.

Для этого в чате Claude Code, в поле ввода достаточно ввести слэш команду - /context

Прикрепляю скриншот как это выглядит вживую

И ещё такое впечатление, что Claude Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.

Так что, удачи всем с проектами на этой бурной трудовой неделе!))