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

У индустрии есть любимая форма самоуспокоения. Каждый раз, когда речь заходит про AI в разработке, люди начинают обсуждать качество кода. Смотрят на демки, ловят модель на галлюцинации, смеются над кривыми PR, вспоминают, что она не понимает бизнес-контекст, и на этом месте выдыхают. Кажется, что профессия снова отбилась. Ну да, игрушка интересная, местами полезная, местами смешная, но до реальной инженерной работы ей еще бесконечно далеко.

Легко поддаться этому успокоению, вспомнив первые версии Claude, Copilot или ChatGPT. Многие говорят, что это просто очередной инструмент, как экскаватор вместо лопаты. Ошибка этой аналогии в том, что Copilot - это действительно экскаватор, которым управляет человек. Но агентные системы, работающие в цикле CI/CD, это не инструмент. Когда у вас появляется система, способная самостоятельно делать десятки итераций проверки и исправления за секунды, без участия человека, единица человеческого труда меняется необратимо.

Мне кажется, в этот момент люди смотрят мимо главного.

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

И проблема здесь глубже, чем очередной скачок в генерации кода.

Полгода назад была статья как Яндекс обновляет процесс найма разработчиков - а недавно, в феврале 2026 я вновь опробовал этот "процесс" - и вот поделюсь, насколько он реально "обновился" (т.к. я проходил его и раньше). Одновременно шёл аналогичный процесс с ВК - постараюсь описать сходства и различия по всем этапам, в которых участвовал - может быть полезно и тем кто проходит подобные собеседования - и тем кто формирует процессы найма.

Краткий вывод такой: описанные в той статье «обновления» присутствуют, но значительных изменений не ощущается. В конце выявился «один нюанс», который портит целесообразность процесса изначально (можно сразу пролистать в конец статьи если любопытно). Так что «обновлениям» впереди ещё немалый путь!

А что, если современные технологии для большинства вещей избыточны? В проекте «ЭХО» я решил проверить это на практике, создав цифровую капсулу времени для потомков. Цель — позволить людям оставить память о себе (фото и мысли) в максимально простом и «вечном» формате.

Технически это эксперимент по созданию системы на 250 млн анкет без баз данных, фреймворков и лишних слоев — только чистый Go и минималистичный Linux. В этой статье я поделюсь опытом, как заставить обычный ПК работать с такой нагрузкой, используя лишь стандартную библиотеку и файловую систему.

Переезд с macOS на Windows для разработчика часто сопровождается болью от потери привычного инструментария. В моем случае решающим стимулом свитчнуться на ПК стала мощная видеокарта. Сейчас мой верный MacBook всё так же лежит на столе и даже подключен к мониторам, но по факту именно Windows (как бы сильно она мне ни не нравилась) стала основной рабочей системой.

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

Штатный инструмент Windows (Win+V) разочаровал моментально: лимит в 25 элементов, отсутствие поиска и полное обнуление после перезагрузки ОС. Поиск альтернатив тоже не увенчался успехом: Ditto надежен, но выглядит как гость из 2005 года, а мощный CopyQ имеет перегруженный интерфейс суровой системной утилиты. Ни в одном из них не было современных функций вроде OCR «из коробки» или базовой интеграции с LLM для обработки текста на лету.

Решение напрашивалось само собой — написать свой велосипед. Но сделать его легким, быстрым и без Electron. В этой статье расскажу о том, как устроен Beetroot — менеджер буфера обмена с бесконечной историей, нативным OCR и AI-трансформациями.

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

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

Игроки первого эшелона – Anthropic, OpenAI и Google – не так давно подкинули нам новые версии своих моделей. Конечно, многие ждали выхода новой DeepSeek, но, к сожалению, чуда не произошло. Поэтому в сегодняшнем материале мы сосредоточимся на доступных нам флагманах.

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

Четвертый выпуск еженедельных IT-новостей от OpenIDE. В этот раз: Opus 4.6 решил задачу, над которой Дональд Кнут сидел несколько недель, Cursor официально интегрировался с JetBrains IDE, а домен bot.ai ушёл за $1,2 млн.

Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени.

Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день.

Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.

Я был одержим процедурными картами с ещё детства, когда кидал кубики на таблицы случайных подземелий из AD&D Dungeon Master's Guide. В этом есть что-то волшебное — ты не проектируешь подземелье, а исследуешь его, помещение за помещением, а кубики решают, попадёшь ли ты в сокровищницу или в тупик с кучей крыс.

Спустя годы я решил создать собственный генератор карт. Он создаёт маленькие средневековые островные миры с дорогами, реками, побережьями, горами, лесами и деревьями. И всё это полностью процедурным образом. Генератор написан на Three.js WebGPU с TSL-шейдерами, примерно 4100 шестиугольников в 19 сетках генерируются за ~20 секунд.

Привет! Меня зовут Николай, я C++-разработчик в SimbirSoft. Это продолжение цикла статей о проектировании библиотек на примере решения геометрических задач. В первой части мы разобрали классическое наследование с виртуальными функциями и использование шаблонов, сравнили их сильные и слабые стороны и посмотрели, какие ограничения возникают при расширении системы.

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

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

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

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

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

Когда шок пройдёт, придёт понимание, что любой профессионал обязан использовать агентское программирование.

Как часто вы слышите что-то о протоколе WebSocket? А как часто видели его в проектах? Продакшн? Андроид? Что? Его кто-то использует?

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

Java-разработчики годами жили по принципу «Everything is an object». И всё бы хорошо, если бы за это нам не приходилось платить «налогом на объект»: каждый раз, когда вы создаёте простой класс из двух полей int, JVM бережно дописывает к нему тяжёлый заголовок, упаковывает в ссылку и разбрасывает по куче, заставляя процессор страдать от постоянных промахов кеша.

Мы привыкли к этому компромиссу. Мы научились использовать примитивные коллекции и костыли, чтобы выжать производительность там, где объектная модель Java начинает буксовать. Project Valhalla призван изменить сами правила игры.

Проект PhotoMentor создавался как ИИ-ментор для фотографов. Механика простая: пользователь загружает снимок, а под капотом Gemini выступает в роли арт-директора — анализирует композицию, работу со светом, цветовую гармонию и выдает детальный фидбек с оценкой.

С главной проблемой Vision-моделей я столкнулся в первый же день закрытых тестов. Я скормил Gemini свой тестовый снимок: крупный портрет собаки, положившей морду на лапы.

Модель уверенно выдала:

Вы открываете горячую функцию в профилировщике, видите миллионы вызовов, добавляете #[inline(always)]. Бинарник распухает, время сборки подскакивает, а производительность не меняется. Или ваще падает. Проблема не в атрибуте. Проблема в том, что #[inline] делает совсем не то, что подсказывает интуиция.

Каждый раз, когда вы соединяете ноды в Blueprint и нажимаете Play, Unreal Engine запускает маленький процессор. У него свои инструкции, свой стек, своя защита от бесконечных циклов. Он написан в ~4000 строках C++ и живёт в одном файле. Через него проходит каждый Event Tick, каждый Event BeginPlay, каждый вызов Blueprint-функции.

Этот процессор - Blueprint VM (Virtual Machine). И сегодня мы разберём его по винтикам.

В 1988 году бортовой компьютер с памятью 128 КБ посадил космический корабль в шторм. Сегодня ваш смартфон с многоядерным процессором заикается при скролле списка контактов. Мы привыкли думать, что данные невесомы, а JSON – это «просто текст». В этой статье мы препарируем один обычный fetch-запрос и посчитаем его реальную цену: в байтах, миллисекундах и скрытых архитектурных издержках. Разберемся, почему мы стали «поколением JSON» и как вернуть себе инженерную осознанность в эпоху избыточности.

Разрабатываю AI-агента персональной аналитики для себя вместе с Claude Code. Любопытной инженерной задачей оказалась архитектура памяти. Как сделать, чтобы агент помнил не только последний разговор, но и паттерны, накопленные за месяцы? В этой статье описана архитектура, рабочие решения и грабли, на которые я наступила.

TL;DR: Ваша IDE знает о проекте всё — иерархии типов, ссылки между модулями, исходники библиотек, ошибки компиляции. AI-агент ничего из этого не видит и вынужден грепать код и логи. За один выходной можно написать плагин и CLI, которые выставят семантику IDE наружу — и агент получит те же суперсилы, что и вы. В статье — как это сделано на примере Eclipse и JDT, но подход переносим на любую IDE. Открытый код: github.com/kaluchi/jdtbridge.

Если ваши руки давно привыкли к Ctrl+Shift+G, Ctrl+T, Ctrl+Shift+T и сопротивляются переходу в другой редактор — вы, вероятно, в Eclipse. И вы точно знаете, что ваша IDE понимает код на уровне, который не снился ни одному AI-редактору. Но AI-агент об этом не в курсе, и как следствие, вынужден жечь десятки тысяч токенов на свои grep-ы.

Обратная сторона лаконичности знаков в языках программирования. Правила отсеивания неподходящих вариантов при выработке системы знаков для языка программирования.

Хочу рассказать о том, как я создавал tg бота на локальной LLM Ollama и с какими проблемами я столкнулся. Бот написан на python и библиотеке telegram.

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

Модели я подбирал под свой компик: 5070 и 32 гб оперативы. Сервера своего нету, поэтому бот работает только когда я дома.

Бот продолжает развиваться. Следить за обновлениями и новыми фичами можно в моем Telegram-канале: https://t.me/rocet_0