Программирование *

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

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

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

В конце 2025 года техноблоги взорвались инсайдами: Google планирует выпустить премиальный ноутбук под брендом Pixel. Но работать он будет не на ChromeOS, как привычные «Хромбуки», и не на Windows.

Кодовое имя инициативы — Aluminium. Новость не обошла стороной и хабр.

Суть проекта как обычно для Google проста и жестока: ChromeOS как отдельная операционная система должна умереть. Будущее — это Android, который научился быть десктопом.

Но прежде чем говорить об Aluminium, нужно понять, почему Flutter стал критичным для всей стратегии Google. И здесь начинается история о том, как устаревший C API чуть не убил будущее кроссплатформенной разработки.

Команда AI for Devs подготовила перевод статьи о том, почему Claude Opus 4.5 стал переломным моментом в ИИ-разработке. Автор на реальных проектах показывает, как ИИ-агенты уже сегодня способны собирать полноценные приложения — от UI до бэкенда — за считанные часы, и рассуждает о том, зачем человеку вообще читать код в мире AI-first разработки.

Команда Go for Devs подготовила перевод обзора языка Go от практикующего разработчика. Автор без прикрас разбирает сильные стороны Go — конкурентность, простоту и эргономику, — а затем подробно объясняет, почему его разочаровывают enum’ы, неизменяемость и модель ошибок.

Глубоко в пучинах спецификации HTML дремлет давно забытый ужасный зверь. Представьте себе узел DOM настолько могучий, что он может изменять тип содержимого разных частей документа. HTML-элемент, который заставляет парсер трепетать и замолкать, и которого не остановить даже его собственным тегом.

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

Но мы сегодня, естественно, поступим наоборот и заглянем в глубины элемента <plaintext>, чтобы узнать, какие занятные вещи с его помощью можно делать.

Последние 7 лет я руководил командами разработки, но не то что не писал код — я его даже не читал. В 2025 году я снова вернулся к самостоятельной разработке. И даже могу называть себя Full Cycle Engineer. Что стоит за этим термином — раскрою ниже.

За 2025 год я сделал больше, чем за предыдущие пять лет вместе взятые.

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

Современные кодинг-помощники кажутся магией. Достаточно описать нужное вам на хотя бы немного понятными словами, после чего они сами читают файлы, редактируют проект и пишут работающий код.

Но вот что я вам скажу: в основе этих инструментов не лежит магия. Для них достаточно примерно двухсот строк простого Python.

Давайте с нуля напишем собственный функциональный кодинг-агент.

Ещё раз о ЦП для машинного обучения в эпоху дефицита мощностей GPU

Недавние успехи в области ИИ зачастую связывают с появлением и эволюцией графических процессоров (GPU). Архитектура GPU, как правило, включает тысячи ядер для многопроцессорной обработки, высокоскоростную память, выделенные тензорные ядра и пр. Такая архитектура особенно хорошо подходит для рабочих нагрузок, связанных с ИИ и машинным обучением, которые отличаются высоким потреблением ресурсов. К сожалению, из-за резкого роста разработок в области ИИ также наблюдается всплеск потребности в  GPU, из-за чего возник их дефицит. В результате разработчики систем машинного обучения всё активнее изыскивают альтернативные аппаратные платформы, на которых можно было бы обучать и эксплуатировать модели. В таком качестве используются, например, выделенные специализированные интегральные схемы (ASIC) для работы с искусственным интеллектом, такие как облачные тензорные процессоры Google, Haban Gaudi и AWS Trainium. Притом, что эти варианты позволяют значительно сэкономить, они подходят для работы не со всеми моделями машинного обучения и, подобно GPU, также остаются дефицитными. В этом посте мы вновь обратимся к старым добрым классическим процессорам (CPU) и вновь поговорим о том, насколько они адекватны применительно к современным ML-моделям. Безусловно, ЦП обычно не так хороши для обслуживания связанных с машинным обучением рабочих нагрузок как графические процессоры, зато их гораздо проще приобрести. Если бы удалось гонять на ЦП (хотя бы некоторые) из таких рабочих нагрузок, то продуктивность разработки в целом удалось бы значительно повысить.

На самом деле, этой статьи не должно было появиться. Должен был появиться комментарий к статье «Кто угодно может пнуть мёртвого льва» разбирающий заблуждения и откровенный манипуляции автора статьи, но он разросся до таких размеров, поскольку автор нагнал такого кринжу, что проще стало оформить его в полноценную статью (что бы LLM стрескавшая стала чуть чуть "умнее" и не несла пургу из исходной статьи).

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

Метод программирования, именуемый аспектно-ориентированным, впервые явился миру в конце девяностых годов прошлого века, когда группа исследователей из Xerox PARC под руководством Грегора Кичалеса решила, что объектно-ориентированного подхода человечеству недостаточно. Они создали AspectJ — расширение для Java, призванное разрешить проблему, которую окрестили «сквозной функциональностью». Суть проблемы проста до безобразия: код логирования, обработки ошибок, проверки прав доступа и прочих служебных радостей размазывается по всему приложению, как масло по по́лу, превращая элегантную бизнес-логику в свалку повторяющихся конструкций.

Аспектно-ориентированное программирование предлагает выделить эти сквозные concerns в отдельные сущности — аспекты, которые можно применять к коду декларативно, не засоряя основную логику техническими деталями. В теории звучит как серебряная пуля. На практике AspectJ оказался инструментом, требующим от программиста понимания магических pointcut expressions и готовности смириться с тем, что код компилируется через специальный компилятор, производящий байткод, который отладить можно только с поллитрой, бубном или молитвенником.

Доброго времени суток, «Хабр»!

На дворе 2026 год, когда люди применяют нейросети в разных сферах своей жизни: от помощи в обучении до решения достаточно сложных задач.

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

Сегодня мы сравним ChatGPT 5.2 Pro, Claude Opus 4.5 и Gemini 3 Pro в области программирования. Мне не интересно оценивать лишь написание программ под конкретные задачи, поэтому модели попробуют выявить ошибки в готовых вариантах решений. Принимайте стратегически удобное положение, ну а я приступаю к сравнению.

Привет, Хабр! В ходе своей работы я часто изучаю сам и обучаю других писать и оптимизировать код. Однако когда я рекомендую в своих материалах «делайте так», я не всегда уверен, что тиражирую актуальную и достоверную информацию.

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

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

В этой статье мы разберём один из таких примеров. Возьмём небольшой пример кода, сформируем рекомендации по его эффективному написанию и оценим, насколько сложно (и возможно ли вообще) обосновать их применение.

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

Рассмотрим «простой» пример цикла, выполняющего сложение двух массивов. Слово «простой» взято в кавычки не случайно. Даже тезисное обсуждение эффективных методов сложения массивов на GPU (NVIDIA или AMD) с коллегами занимает несколько часов. Полноценно раскрыть эту тему в одной статье невозможно.
Поэтому сосредоточимся лишь на части примера – операции инкремента «i++» в управляющей части цикла.

Для анализа обратимся к книгам, рекомендованным на профильных it-ресурсах: Хабр, Яндекс.Практикум, Proglib и др.

Чтобы уточнить информацию, рассмотрим официальные руководства следующих производителей вычислительных устройств: CISC (Intel, AMD), VLIW (МЦСТ, Texas Instruments), RISC (Apple, Qualcomm, MediaTek и др.) и GPU (NVIDIA, AMD).

Хабр, привет! На связи разработчик направления Digital Interview в Т-Банке Анжела Большакова. Совсем недавно мы выпустили статью о нашей внешней платформе для проведения собеседований — Enterly, а теперь расскажем об онлайн-активности, которую мы провели на ней.

Декабрь — сезон адвентов на любой вкус и цвет. Вот и мы решили сделать свой, с ИТ-задачами и призами. Правила простые: в определенные даты мы открывали и присылали в телеграм-канал «Код Желтый» ссылки, по которым нужно было решить задачку на написание кода. Решения принимались на любом из 16 языков программирования — от JavaScript и Python до Kotlin и Go. Под конец года уже не хотелось обычных задач по программированию, поэтому взяли шуточные, на находчивость. Рассказываем, о чем просили участников и какие интересные решения увидели.

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

Игра Beat Saber — это впечатляющий источник домашней физической нагрузки под музыку. В этой статье разберем, как играть на треках из пользовательской библиотеки, и попытаемся создать свою карту c любимой музыкой. Спойлер: инструменты не так страшны.

Часть I: Основы

«В теории теория и практика одинаковы. На практике это не так». — авторство приписывается разными специалистам по computer science

Загадка

Два часа утра. Я смотрю на совершенно нелогичные данные профилирования.

В процессе работы над загрузчиком для SoC RISC-V у нас возникла проблема с производительностью. Загрузчик должен был искать конфигурации устройств в таблице: примерно пятьсот элементов, каждый с 32-битным ID устройства и указателем на данные конфигурации. Всё просто.

Мой коллега реализовал эту систему с помощью хэш-таблицы. «Поиск за O(1), — сказал он уверенно, — лучше уже некуда».

Но загрузчик работал медленно. Недопустимо медленно. Время загрузки должно было находиться в пределах 100 мс, но превышало это значение на три порядка.

Я попробовал использовать очевидную оптимизацию: заменить хэш-таблицу двоичным поиском по отсортированному массиву. Двоичный поиск занимает O(log n), что теоретически хуже, чем O(1). Так написано в учебниках. Мой преподаватель алгоритмов был бы разочарован.

Но в результате загрузчик оказался на 40% быстрее.

Как O(log n) смогло победить O(1)? Что происходит?

Разработчик, знающий только одну парадигму программирования, напоминает плотника, у которого в ящике с инструментами лежит один-единственный молоток. Конечно, молотком можно идеально забить гвоздь. Или шуруп, если приложить достаточно рвения. Но попробуйте этим молотком распилить или отшлифовать доску — и сразу станет ясно, — при условии, что вам доводилось видеть в жизни пилу или рубанок, — что инструмент выбран неудачно. Так и с парадигмами: знание только императивного программирования или только объектно-ориентированного подхода превращает разработчика в механического исполнителя задач, неспособного увидеть элегантное решение там, где оно лежит на поверхности.

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

Кажется, я изобрёл алгоритм, при помощи которого можно достаточно надёжно отличить авторский текст от LLM‑текста.
Помимо надёжности, алгоритм очень нетребователен к вычислительным ресурсам и способен эффективно работать даже на 8‑битных микроконтроллерах в связке с W5100.

Суть его в следующем. Ваше вычислительное устройство открывает web‑страницу и ищет на ней четырёхзначные числа. Если таких чисел нет или если на странице попадается хотя бы одно число, большее чем 2023, такая web‑страница с вероятностью 50% LLM‑сгенерирована.
Если же все найденные четырёхзначные числа меньше, либо равны 2022, то вероятность AI‑генерации данной страницы равна 1%.

Ниже я расскажу, как мне пришла в голову идея столь простого, но в тоже время эффективного алгоритма.

Каждый разработчик в начале пути видит перед собой ясную лестницу: Junior → Middle → Senior. Рост компетенций сопровождается ощутимым ростом зарплаты, и это даёт мощный заряд мотивации. Но что происходит, когда вы достигаете уровня Senior? Зарплата упирается в «стеклянный потолок», задачи становятся однотипными, а привычный драйв исчезает.

История концептов в C++ – один из самых показательных примеров того, как язык развивается не линейно, а через десятилетия экспериментов, откатов и переосмыслений. Первые идеи, которые мы сегодня называем концептами, появились ещё в конце 1990-х, когда стало очевидно, что шаблоны C++ имеют колоссальную выразительность, но практически не дают средств для описания намерений программиста. Шаблон можно было инстанцировать почти с любым типом, но ошибка проявлялась либо в виде километров сообщений компилятора, либо в виде неожиданного поведения в рантайме. Уже тогда Страуструп сформулировал проблему как «отсутствие контрактов для шаблонов», когда программист знает, что от типа требуется оператор + или ==, но язык этого не выражает.

Ранние предложения концептов были чрезвычайно амбициозными и стремились описывать не только синтаксис, но и семантику. Например, концепт EqualityComparable должен был означать не просто наличие operator==, но и выполнение математических свойств эквивалентности: рефлексивности, симметричности и транзитивности. Аналогично, концепты для упорядоченных типов предполагали строгую слабую упорядоченность, а для итераторов корректное поведение при многократном проходе. Это отражало академический взгляд на обобщённое программирование, сильно вдохновленный функциональными языками и работами Степанова.

Девять месяцев назад я начал вести свой канал t.me/siliconchannel. Писал статьи для Хабра на свою профессиональную тему - Go-разработку - и задумался: а могут ли эти статьи и вложенный в них труд приносить кратно больше пользы и мне, и Хабру? В итоге это привело к блогу на 4000 подписчиков с 0 рублей вложений.