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

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

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

Как я автоматизировал превращение вайбкодерского PoC в production-ready MVP

За несколько часов с помощью AI можно собрать работающий PoC: интерфейс открывается, кнопки нажимаются, основной сценарий проходит.

Потом кто-нибудь спрашивает:

А это уже можно выкатывать в прод?

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

Мне регулярно приходится заниматься именно второй половиной этой работы — превращать быстро собранные прототипы в поддерживаемые MVP.

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

Под капотом — один постоянный Reviewer, временные Workers, 41 специализированное ревью и простой цикл:

Review → Plan → Implement → Re-review

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

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

После вайб-кодинга: почему в 2026 году появляется новый класс Code Clean-up Agents. Как стоимость разработки смещается от генерации к проверке, рефакторингу и контролю изменений

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

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

В этой точке полезно отделить генерацию патча от подготовки изменения к отправке в основную ветку. Для второй задачи в 2026 году формируется отдельный класс инструментов: Code Clean-up Agents.

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

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

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

Как часто, работая с агентом над новой фичей, вы остаётесь недовольны результатом? То что-то не работает, то качество кода неприемлемо. Вы просите агента ещё раз и ещё раз, пытаетесь подобрать «идеальный» промпт — и всё равно не выходит. Уверен: чем дольше вы работаете с агентом, тем чаще разочаровываетесь. И это неудивительно: агент пишет код очень быстро — и именно поэтому ОЧЕНЬ просто получить ОЧЕНЬ много кода, который вам не нужен. Но код — это как раз простая часть. Настоящая задача инженера — строить системы: надёжные, быстрые и поддерживаемые. Именно за это нам и платят — и вот этого агент пока за нас не делает.

У каждого релиза Postgres свой характер.

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

В Postgres 19 есть улучшения на любой вкус. Встроенная команда REPACK CONCURRENTLY упрощает обслуживание крупных рабочих баз данных. SQL-запросы к графам свойств наверняка привлекут много внимания. Логическая репликация становится полноценнее.

Разработчики также улучшили VACUUM, EXPLAIN, COPY, секционирование, мониторинг и планировщик. Эти изменения не так заметны, но упрощают эксплуатацию рабочих систем.

До финального релиза детали могут измениться. Но бета-версия Postgres 19 уже позволяет оценить новые возможности и понять, как они повлияют на разработку и эксплуатацию систем.

Каждый C#‑разработчик писал numbers.Where(x => x > 10).Select(x => x * 2) — и удивлялся, узнав, что эта строчка ничего не вычисляет. Цепочка спит, пока мы не начнём перебирать результат.

За этим стоит конкретный механизм — отложенные вычисления, а в его основе лежит обычная фича языка: yield. Разбираем, как устроены ленивые методы LINQ изнутри — от ручной реализации Where без yield до того, во что этот yield разворачивается компилятором.

А вы точно знаете, что происходит под капотом каждый раз, когда пишете .Where(...).Select(...)?

К статье приложен репозиторий с полной реализацией.

Несмотря на то, что WebStorm уже несколько лет официально недоступен в России, он по-прежнему остаётся одним из главных инструментов для веб-разработчиков. Недавно вышла новая версия WebStorm 2026.2.

В релиз вошли поддержка TypeScript 7, нативная интеграция с GitHub Copilot, менеджер скиллов для ИИ-агентов и обновления для React, Vue, Svelte, Angular и других популярных технологий. Разработчики также улучшили отладку, работу с Node.js и Git, производительность и стабильность IDE.

В статье разберём основные изменения WebStorm 2026.2, а также расскажем, какие возможности для веб-разработки уже доступны в OpenIDE и чего ожидать от её предстоящего перехода на платформу 2026.2.

Origami Framework — фреймворк для автоматизации тестирования на Java, созданный с целью упрощения построения тестовой архитектуры и ускорения процессов приёмочного и регрессионного тестирования

Всем привет!
Меня зовут Шадрин Дмитрий.
Хочу поделиться собственными наблюдениями и практическим опытом использования AI в производственной разработке.
За последний год вокруг искусственного интеллекта в разработке появилось огромное количество материалов.

Кажется, что каждую неделю появляется новая модель, новый IDE-плагин или очередной инструмент, который обещает ускорить разработку в несколько раз. Вокруг этой темы накопилось огромное количество обсуждений. Кто-то сравнивает качество генерации кода у разных моделей, кто-то пытается посчитать, сколько процентов работы разработчика можно автоматизировать уже сегодня, а кто-то всерьёз задаётся вопросом, останется ли профессия разработчика через несколько лет в её нынешнем виде. Эта тема вызывает много споров, эмоций и ожиданий.
Но, наблюдая за тем, как подобные инструменты используются в реальной разработке, я всё чаще прихожу к мысли, что самое интересное происходит совсем не там, где принято искать. На мой взгляд, главный эффект современных AI-инструментов заключается не в генерации кода.
Самые серьёзные изменения происходят в работе с контекстом. Современные AI-инструменты начинают автоматизировать задачи анализа требований, навигации по кодовой базе, поиска архитектурных зависимостей и оценки влияния изменений (impact analysis). Именно это сегодня начинает менять сам подход к инженерной работе.
Я с большим интересом наблюдаю за всеми этими дискуссиями. Мне самому близка тема инженерных инструментов. За последние годы я успел поработать в разных компаниях, на разных ролях и с очень разными системами.
Сейчас я занимаюсь развитием корпоративных систем для оптовой торговли, франчайзинговых партнёров и интеграции с маркетплейсами в компании SM Lab. До этого был опыт работы в финтехе Яндекса, где приходилось проектировать и запускать сервисы, работающие под высокой нагрузкой и в условиях серьезных регуляторных ограничений.

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

По общим тезисам каждый может проверить выводы у себя.

Записи вебинаров на RuTube / YouTube: 

Вебинар 1 — AI-инструменты для разработчиков 2026 

Вебинар 2 — Настройка проекта под агента

Вебинар 3 — Как работать с ИИ-агентом: SDD, TDD, самопроверка и субагенты

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

Представьте: вы пишете парсер, который обходит сотни миллионов URL. Каждую новую ссылку нужно проверить — посещали ли мы её раньше? Заводить гигабайтный хеш-набор для хранения всех адресов — расточительно и медленно.

Но существует вероятностная структура данных, которая способна ответить на вопрос «видели ли мы этот URL?», занимая при этом в десятки раз меньше памяти, чем полное множество строк. Плата за такое — мизерная возможность ложноположительного срабатывания, где алгоритм заявит что URL есть, хотя на самом деле он новый. Зато на вопрос «не видели?» она не ошибётся никогда.

Это и есть Фильтр Блума, созданный Бёртоном Блумом аж в 1970 году. Более полсотни лет этому алгоритму! В принципе, никогда не помешает освежить знания и вспомнить, как писать реально оптимизированное ПО.

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

Здесь кроется главное противоречие внедрения LLM. Без доступов агент бесполезен, а с ними — превращается в потенциально опасного инсайдера. Любая ошибка в чате может обернуться реальным запросом к системе от имени служебного аккаунта, и ограничения в промпте вроде «не брать чужое» здесь не помогут.

Именно этот разрыв между красивым демо и суровой энтерпрайз-реальностью стал темой дискуссии на канале Ai4Dev.

ИИ увеличивает продуктивность разработчиков на 55% — по крайней мере, к такому выводу пришли в этом исследовании.

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

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

Сейчас часто можно услышать мнение, что LLM и AI-агенты способны значительно снизить стоимость разработки. Вместо того чтобы расширять команду, достаточно дать задачу модели, и она выполнит работу за минуты.

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

Семнадцать лет назад Брэндон Шеффилд собрал на Gamasutra классическую подборку «Dirty Coding Tricks», перевод на Хабре тут, и «Developers share their most memorable dirty coding tricks» где были камера, повёрнутая на 90 градусов вместо починки рендера, пробел, добавленный в код ради совпадения контрольной суммы, и два мегабайта памяти, спрятанные «на чёрный день», чтобы торжественно достать их за неделю до сдачи.

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

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

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

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

Казалось бы, современный C++ дает нам море инструментов для контроля кода на этапе компиляции: static_assert, концепты, constexpr всё, что только можно. Но что делать, если вам нужно заставить разработчика вызвать обязательную функцию инициализации инфраструктуры тестирования для библиотечных классов, а проект собирается под ARM с агрессивным -O2 -Os -flto=auto в недрах Yocto/OpenBMC?

В этой статье я расскажу, как попытка добавить удобный режим тестирования для датчиков которые используют header-only библиотеку столкнулась с невероятно умным оптимизатором GCC 14.2, и почему в эпоху мегабайтных исходников нам всё ещё приходится спускаться на уровень инлайн-ассемблера, чтобы просто заставить линкер выдать ошибку для не корректного кода (для определения правила использования хидера).

Продолжение здесь.

Несмотря на то, что IntelliJ IDEA уже несколько лет официально недоступна в России, она по-прежнему остаётся одной из самых популярных IDE среди разработчиков. На днях вышла свежая версия 2026.2.

В релиз вошли новые инструменты для работы с ИИ-агентами, изменения в отладчике и автоматизация ряда повседневных операций. Также появилась поддержка Java 27, Kotlin 2.4, TypeScript 7, будущего Gradle 10 и обновления для Spring, Terraform и Docker Compose.

В статье пройдемся по основным изменениям.