Вчера Cursor (популярный ИИ-редактор кода) представил Debug Mode — новый режим отладки, где искусственный интеллект работает в связке с разработчиком, а не пытается все решить самостоятельно.
Как это работает
Обычные ИИ-агенты для кода пытаются сразу исправить баг — часто генерируя сотни строк спекулятивного кода, который может не решить проблему. Debug Mode работает иначе.
Шаг 1: Описываете баг
Выбираете Debug Mode и описываете проблему. ИИ читает вашу кодовую базу и генерирует несколько гипотез о том, что могло пойти не так. Часть идей будут очевидными, но другие — такими, о которых вы сами не подумали бы.
Вместо того чтобы сразу писать фикс, ИИ добавляет в код логирование для проверки этих гипотез.
Шаг 2: Воспроизводите баг
Вы идете в свое приложение и воспроизводите баг, а ИИ в это время собирает runtime-логи: состояние переменных, пути выполнения, тайминги.
С этими данными ИИ точно понимает, где проблема, и предлагает целевое исправление — обычно 2-3 строки кода вместо сотен строк гаданий на кофейной гуще.
Шаг 3: Проверяете фикс
Debug Mode просит вас воспроизвести баг еще раз — но уже с предложенным исправлением. Если баг исчез, вы отмечаете это, и ИИ убирает все логи, оставляя чистое минимальное изменение.
Если баг остался — ИИ добавляет больше логирования и уточняет подход, пока проблема действительно не будет решена.
Почему это важно
Ключевая идея Debug Mode — человек всегда в центре процесса. ИИ делает рутинную работу: инструментирует код, собирает данные, генерирует гипотезы. А вы принимаете все важные решения: действительно ли баг исправлен, подходит ли решение технически и концептуально.
Как пишут разработчики Cursor:
"ИИ справляется с рутиной, пока вы делаете быстрые решения, требующие человеческого суждения. Результат — баги, которые раньше были недоступны даже самым умным моделям, теперь надежно исправляются"
Это противоположность "vibe coding", где ИИ получает автономию и может натворить дел. Debug Mode показывает, как должны работать ИИ-агенты в критических задачах: помогают, но не заменяют разработчика.
P.S. Поддержать меня можно подпиской на канал "сбежавшая нейросеть", где я рассказываю про ИИ с творческой стороны.
В этой статье я расскажу о SSD размером с монету, который оставляет далеко позади обычные карты памяти, и о чумавом планшете с жидкостным охлаждением. Читайте, как Трамп спасает ИИ от бюрократии и о чем договорились Москва и Тегеран, в нашей подборке.
2 терабайта весят 1 грамм
SSD накопитель CL100. Источник: Biwin
Компания Biwin (это крупный китайский OEM-производитель памяти) наконец-то выпустила в продажу накопители формата Mini SSD (модель CL100). Главная фишка это скорость. Обычные microSD карты, даже самые дорогие, нервно курят в сторонке. Скорость чтения у этого гиганта 3700 МБ/с, а скорость записи до 3400 МБ/с. Для сравнения: даже новый стандарт microSD Express выдает около 985 МБ/с. Mini SSD быстрее почти в 4 раза.
Поскольку этот чип может часто путешествовать в кармане, Biwin его закалила: Защита IP68 не боится воды и пыли. Переживет падение с 3-х метров на твердую поверхность. Ресурсы от 512 ГБ до 2 ТБ.
Mini SSD не распаян на плате и не спрятан в недрах ноутбука под крышкой с десятью винтами. Он вставляется в лоток, как SIM-карта. Захотел расширить память? Тыкнул скрепкой, достал лоток, поменял накопитель.
Цены в Китае пока такие:
512 ГБ стоит ~85$
1 ТБ стоит ~155$
2 ТБ стоит ~311$
Кардридер RD510. Источник: Biwin
Biwin также выпустила кардридер RD510 с подключением по USB4 (40 Гбит/с). И знаешь, что в нем интересного? Встроенный вентилятор. Это намекает нам на то, что при таких скоростях и размерах малютка CL100 будет греться как кипятильник.
Планшет, который хочет быть игровым ПК
Фото OneXPlayer на Kickstarter. Источник: OneXPlayer
Компания OneXPlayer выходит на Kickstarter с новым проектом, который они скромно назвали Super X. Это, похоже, самый мощный Windows-планшет в мире. Внутри него бьется новейшее сердце от AMD, процессор Ryzen AI Max+ 395. Для тех, кто не следит за каждым чихом AMD, это флагманская 16-ядерная махина на архитектуре Zen 5 с интегрированной графикой Radeon 8060S.
Да, тут нет дискретной видеокарты, но, по заявлениям OneXPlayer, производительность этой встроенной графики находится на уровне NVIDIA GeForce RTX 4060. Если это правда, то в разрешении 2.8K можно будет играть во что угодно.
Самая безумная деталь это система охлаждения. Super X это первый в мире планшет с поддержкой внешней системы жидкостного охлаждения (СЖО). Внутренний кулер, вероятно, основанный на испарительной камере, интегрирован в тонкий алюминиевый корпус толщиной всего 12,5 мм, но он рассчитан на поддержку до 120 Вт теплового пакета.
"Более чем в 3 раза выше производительность ИИ-процессора NPU нового поколения". Источник: AMD
Планшет оснащен 14-дюймовым OLED-дисплеем с высоким разрешением 2880 × 1800, поддержкой HDR и переменной частотой обновления (VRR). То есть, кроме мощности, тут еще и картинка будет сочная. Плюс, возможности для ИИ: процессор включает выделенный нейропроцессор NPU XDNA 2 с производительностью 50 TOPS, который позволяет на самом устройстве запускать огромные языковые модели, вроде DeepSeek 70B.
Стартовая цена на Kickstarter для базовой версии (Ryzen AI Max 385, 32 ГБ ОЗУ, 1 ТБ SSD) заявлена в $1900. Доплатить всего $100 и получишь топовый Ryzen AI Max+ 395. Учитывая, что речь идет о планшете с потенциально 128 ГБ сверхбыстрой оперативной памяти LPDDR5X-8000, ценник в $1900 выглядит хоть и внушительно, но для заявленной производительности почти как поход в магазин за хлебом.
Трамп vs. 50 штатов
Президент США Дональд Трамп (в очередной раз) потряс инфополе громким заявлением. Он намерен подписать указ о введении единых федеральных правил регулирования искусственного интеллекта. По его словам, это критически важно, чтобы не дать американскому лидерству в сфере ИИ утонуть в болоте бюрократии.
Политическая реальность в США такова, что помимо общенациональных законов, каждый из штатов имеет право вводить собственные локальные правила. И пока федерального закона об ИИ нет, штаты начинают принимать собственные нормы. Трамп считает, что эта разрозненность смертельно опасна для развития технологий.
Он прямо заявил. что если компаниям придется получать 50 разных разрешений для запуска одного продукта или исследования, это "разрушит ИИ на корню".
OpenAI бьет тревогу
Генеральный директор OpenAI Сэм Альтман, похоже, немного запаниковал и объявил во всей компании внутренний красный код, это сигнал максимальной тревоги. Причина проста, Google выпустила свою модель Gemini 3, которая по ряду ключевых тестов производительности обогнала ChatGPT и начала стремительно переманивать пользователей. Ситуация зеркальна той, что была в Google, когда три года назад внезапно выскочил ChatGPT и заставил их тогдашнее руководство тоже бить тревогу.
Альтман разослал сотрудникам внутреннее письмо, требуя от них сфокусироваться на улучшении ядра ChatGPT: сделать его быстрее, надежнее, умнее и дать больше возможностей для персонализации. Чтобы высвободить ресурсы, компания поставила на паузу все несущественные проекты.
Это включает в себя даже амбициозные начинания, вроде видеогенератора Sora, агентов ИИ для покупок и здоровья, а также личного помощника Pulse. Все силы, включая целые команды, теперь брошены на совершенствование самого чат-бота.
Самый ажиотажный результат этой паники – резкое ускорение выхода следующей модели. OpenAI экстренно форсирует релиз GPT-5.2, который, по слухам, должен был выйти позже в декабре, но теперь ожидается уже на этой неделе.
Сейчас им важно не потерять свои 800 миллионов еженедельных пользователей и выполнить амбициозный план по доходам, который к 2030 году должен достичь сотен миллиардов долларов.
Договорничок Москвы и Тегерана
Россия и Иран заметно углубляют свое технологическое партнерство. По итогам пятого заседания совместной рабочей группы по информационным технологиям, страны подписали солидный документ о сотрудничестве, в котором главное место отведено искусственному интеллекту.
ИИ тут только верхушка айсберга. Документ включает работу над кибербезопасностью, развитием цифровой экономики, внедрением электронного правительства, а также освоением блокчейна и финтеха.
В тексте соглашения есть явный акцент на укрепление связей с частным сектором и развитие технопарков. Такое партнерство вписывается в общую российскую стратегию. В Москве не скрывают амбиций: недавно звучали прогнозы о том, что ИИ к 2030 году должен дать экономике РФ свыше €110 млрд.
AMD наносит удар
Источник: AMD
AMD готовит очередной мощный подарок геймерам. Речь идет о процессоре Ryzen 7 9850X3D. Хотя AMD его официально еще не анонсировала, чип уже успел просочиться и на официальный сайт компании, и в бенчмарки, и даже в транспортные накладные.
Так в чем же главная интрига? Процессоры AMD с индексом X3D (использующие дополнительный кэш 3D V-Cache) давно считаются лучшими для игр. Новый 9850X3D является прямым наследником этой линейки, но с одним очень важным апгрейдом по сравнению с существующим 9800X3D. У него те же 8 ядер и 16 потоков, но рабочая частота поднята сразу на 400 МГц, с 5,2 ГГц до 5,6 ГГц. Это серьезный прирост, учитывая, что процессоры с 3D V-Cache обычно очень чувствительны к частотам.
Первый же слитый тест в бенчмарке PassMark показывает, что разница есть, хоть и небольшая. 9850X3D в многопоточном режиме обходит своего предшественника примерно на 5%. Это не оглушительный отрыв, но для игрового процессора, где важна каждая доля кадра в секунду, такой прирост только за счет частоты это отличный результат.
Интересный момент обнаружился, когда 9850X3D засветился в паре с безумно быстрой оперативной памятью DDR5-9800. Если предыдущее поколение X3D-чипов не очень любило высокочастотную память, то похоже, в новой линейке 9000-й серии AMD снимает это ограничение.
Кстати, по слухам, вместе с этим 8-ядерником AMD может показать нечто совсем дикое – Ryzen 9 9950X3D2, который якобы получит сразу два чипа 3D V-Cache.
Источник: AMD
Альтман собрался в космос
Источник: Stoke Space
Сэм Альтман решил, что Земля для его амбиций стала тесновата. Выяснилось, что гендиректор OpenAI вел очень серьезные переговоры с ракетным стартапом из Сиэтла под названием Stoke Space. Альтман хотел выкупить контрольный пакет акций ракетной компании, чтобы начать вывозить дата-центры прямо на орбиту.
Обучение и работа ИИ потребляют электричество в чудовищных масштабах. На Земле энергия стоит денег и портит экологию, а в космосе солнце светит бесплатно и круглосуточно. Альтман в подкастах уже рассуждал о строительстве Сферы Дайсона, потому что на планете места и энергии для серверов скоро физически не останется. Stoke Space со своей полностью многоразовой ракетой Nova нужна, чтобы доставлять железки в космос.
Ракета Nova от Stoke Space
Покупка Stoke Space стала бы для Альтмана личным вызовом Илону Маску. Владелец SpaceX уже давно намекает, что его новые спутники Starlink V3 будут работать не только как раздатчики интернета, но и как орбитальные сервера. Google и Безос тоже смотрят в эту сторону, так что намечалась знатная драка миллиардеров за то, чей суперкомпьютер будет летать выше.
Но сделку поставили на паузу. Gemini 3 так сильно наступил на пятки OpenAI, что Альтману пришлось резко свернуть космические карты и срочно спасать ChatGPT. Сейчас компании явно не до строительства ракет, тут бы лидерство в чат-ботах удержать.
Если понравилась статья - рекомендую подписаться на телеграм‑канал NetIntel. Там вы сможете найти множество полезных материалов по IT и разработке!
Почему каскадная модель не так «жёстка», как кажется, а Agile — не методология.
На написание статьи сподвигла статья с Хабра и обсуждения в чате одного сообщества по бережливому производству.
Хочу сразу обратить внимание, что здесь будем обсуждать ложную дихотомию в управлении проектами.
Споры о превосходстве Agile над Waterfall или наоборот давно стали клише в IT-среде. Однако корень этой дискуссии — фундаментальное непонимание сути обеих концепций. Agile часто ошибочно называют методологией, тогда как на деле это набор ценностей, а выбор реальных инструментов управления происходит между каскадной моделью (Waterfall) и итерационными подходами — Scrum, Kanban, XP. Почему этот нюанс так важен? Потому что смешение философии и инструментов ведёт к мифам, которые мешают эффективно управлять проектами.
Кажется, что waterfall (каскад) это старая и неповоротливая система
Agile — это ценности, а не методология
Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.
Если коротко, то Аджайл - это крик души замученного разработчика
Waterfall: миф о жестком подходе
Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.
Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:
Техническое задание
Эскизный проект
Технический проект
Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)
Внедрение (Подготовка и передача программы)
Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:
Устранение ошибок.
Развитие и усовершенствование продукта.
Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.
Ведь в Каскаде обратная связь не запрещена, просто требуется документирование
Почему возникает миф о несовместимости?
Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».
Если немного утрировать, то противопоставляя гибкую разработку каскадной, говорят, что строители будут строить дом по неправильному проекту без изменений, пока всё не рухнет, и только потом встанут, отряхнутся от пыли и скажут: - Давайте заново начнем.
Однако в реальности:
Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками. Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum. Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.
Кажется, что это разные подходы, но это не так
Синтез вместо конфронтации: гибридные подходы
На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например: Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.
Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.
Например работа по непосредственной разработке ПО может идти итеративно, спринтами
Как же выбирать методологию? Нужно опираться на критерии, а не догмы Выбор между Waterfall и итерационными методами зависит от четырёх факторов:
Предсказуемость требований. Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.
Стоимость изменений. В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.
Регуляторные ограничения. В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.
Культура команды и заказчика. Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.
Выбор методологии зависит от многих вводных. Но нужно понимать плюсы и минусы каждой.
Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum
Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:
Какова степень неопределённости требований?
Какие ограничения накладывают регуляторы или бюджет?
Насколько команда и заказчик готовы к гибкости?
Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:
Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».
Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).
Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.
Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.
В прошлых постах мы рассказывали про подготовку к сборке уровня, а сегодня приступим к самому интересному - самой сборке вплоть до финального результата. Итак…
- Сборка блокаута. Имея на руках референсы и набросок, можно начинать собирать первый игровой прототип уровня. Он не должен быть детализированным, но обязан быть интересным и приятным в прохождении. На этом этапе проверяются метрики и добавляются базовые механики.
- Настройка событий. Этот этап происходит одновременно со сборкой блокаута и является его неотъемлемой частью. События влияют на то, какие ощущения испытывает игрок во время прохождения, какие механики и действия ему доступны. Сюда можно отнести расстановку чек-поинтов в гоночном режиме, расставление ловушек и “абилок”, добавление интерактивности: взрывающиеся двери, сбивающие насмерть поезда, ломающиеся от удара предметы, запуск примитивных анимаций и кат-сцен.
- Тестирование. Оно проводится постоянно и с разным количеством людей. С помощью него можно проследить понятные и непонятные места на уровне, можно заметить, какие вещи кажутся людям интересными, а какие наоборот - вызывают скуку. Тестирование завершает одну итерацию и начинает новую: блокаут дорабатывается, события донастраиваются. И так пока результат не удовлетворит всю команду.
- Конечный вариант. Он подводит итоги всей проделанной ранее работы. В нём объединяются концепт, основная идея, референсы и наброски, а затем серые кубы блокаута заменяются на готовые модели. Окружение прорабатывается, настраивается освещение, проводится оптимизация.
И на этом всё. Карта готова! Хотя ещё предстоит финальное тестирование и полировка отдельных моментов, но это уже мелочи жизни :)
Про каждый из пунктов создания уровня на самом деле можно было бы расписать по целому посту. Есть очень много технических моментов, разных инструментов и прочего, здесь же мы лишь кратко описали основные моменты. Так что, если интересно, обязательно маякните в комментариях!
Последние пару недель занимаюсь унификацией технологического стека для всех своих pet-проектов и поделок. Цель — собрать единый тех-радар, чтобы не тратить время на переключение контекста между разными фреймворками и библиотеками.
Мой стек
Frontend: - React (без сюрпризов) - WXT (лучший фреймворк для браузерных расширений) - MUI (библиотека UI-компонентов под Material Design) - Netlify (бесплатный и надёжный хостинг)
Backend: - Supabase (как Firebase, только лучше) - Yandex Cloud (serverless-контейнеры + S3-хранилища)
Процесс
На выходных добрался до Speech to Text — браузерного расширения для транскрипции аудио. Оно было написано на vanilla JS ещё в первых версиях, и каждое обновление превращалось в квест по поиску багов и зависимостей.
С помощью Cursor (AI-ассистента для кода) переписал всё расширение за пару часов:
Перенёс на WXT (фреймворк для Chrome Extensions)
Заменил самописные компоненты на MUI
Добавил TypeScript для типобезопасности
Заодно запилил новую фичу: транскрипцию системного звука через Chrome Tab Capture API
Что получилось
Теперь Speech to Text может расшифровывать не только микрофон, но и всё, что играет на компьютере: YouTube-видео, Zoom-созвоны, лекции, подкасты и т.д.
Дополнительно добавил:
Аудиоплеер для предпросмотра файла перед отправкой
Анонимную расшифровку по прямой ссылке на аудио
Бонус
Модерация в Chrome Web Store прошла за 2 часа (обычно было 8-12). Предполагаю, что регулярные релизы дают "репутацию" у алгоритмов Google.
Выводы
Унификация стека — это не просто модное слово, а реальная экономия времени. Теперь могу быстро переключаться между проектами и переиспользовать компоненты без головной боли.
Хотите больше деталей? Про процесс унификации стека, выбор инструментов и другие эксперименты с расширениями пишу в своём Telegram-канале @debug_leg. Там более неформальный формат: короткие посты, скриншоты процесса и честные истории про грабли. Подписывайтесь, если интересна кухня разработки.
👨💻 В 1972 году в Bell Labs Деннис Ритчи создал язык C — фундамент всего современного IT.
Деннис Ритчи
У этого события нет точной даты в календаре, поэтому 10 декабря часто используют как символический день рождения, связывая его с днём рождения первой программистки в истории, Ады Лавлейс.
👨💻 Язык, задуманный для UNIX, стал «латынью» для разработчиков: на нём написаны Windows и Linux, а его синтаксис лёг в основу C++, Java и Python.
===================================================== 👇👇Наш канал на других площадках👇👇 YouTube | VkVideo | Telegram (Ежедневные новости тут) | Pikabu =====================================================
![🗓 10.12.1972 — Рождение языка C [вехи_истории]](https://cs18.pikabu.ru/s/2025/12/10/06/gf2rctj4.jpg)
