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

Всем привет! Меня зовут Андрей, и я работаю в финтех‑направлении Яндекса. Руковожу службой разработки платёжных интерфейсов. Если вы пользуетесь сервисами Яндекса, то наверняка сталкивались с формами оплаты, вот большую их часть делают ребята из моей службы.

Сегодня я расскажу вам о TrustYFox — платформе для поиска уязвимостей в коде при помощи LLM, которую я создал своими руками. С практической точки зрения TrustYFox — это ещё один инструмент, который не заменяет существующие сканеры, а дополняет их, позволяя находить уязвимости.

Статья не претендует на научность или какой‑то RnD, да и я не являюсь экспертом в этих ваших LLM. По большей части это рассказ о том, как получилось (а в итоге получилось) за несколько месяцев пройти путь от прототипа до рабочего решения, в котором ежедневно запускаются аудиты. 

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

14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.

Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.

Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.

Это эссе объемом 2800 слов (на 12 минут чтения) о том, как выжить внутри ИИ-революции в разработке ПО и не поддаться всеобщему страху, витающему вокруг нас. Я поделюсь несколькими уроками, которые усвоил на сложных горных маршрутах — оказалось, они отлично помогают в укрощении ИИ-агентов. Думаю, эти принципы пригодятся всем работникам умственного труда.

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

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

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

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

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

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

Сейчас каждый второй стартап пилит ИИ-агентов. Мы оборачиваем LLM в цикл Промпт -> Вызов инструмента -> Ответ и ждем, что нейросеть сама расследует инцидент, найдет баг или напишет фичу. Но на практике автономные агенты часто ходят по кругу, игнорируют явные ошибки и «влюбляются» в свою первую догадку.

Индустрия пытается лечить это костылями: наращивает контекст до миллионов токенов или заставляет модель «подумать шаг за шагом» (Chain-of-Thought). Я решил проверить эту архитектуру на прочность. Собрал локальный измерительный стенд LOCK-R, вооружился Теоремой Байеса и поймал современные LLM за руку.

В этой статье я математически докажу, почему одиночные агенты структурно уязвимы, как токены размышлений заставляют их врать самим себе еще искуснее, и почему паттерн «Слепого Судьи» - это единственный способ вылечить AI от предвзятости. Тестируем на локальной Qwen-9B и фронтирной GPT-5.4.

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

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

Привет, Хабр!

PostgreSQL умеет блокировать строки (SELECT ... FOR UPDATE) и таблицы (LOCK TABLE). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение.

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

Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

512 000 строк утекшего кода. 44 feature‑флага. Система питомцев в духе тамагочи. Имена вроде «Tengu», «Fennec» и «Penguin mode». Всё это — то, о чём написали сотни новостей. Но не это главное.

Пока интернет разбирал по косточкам внутренности Claude Code, увлечённо споря, игрушка это или серьёзная архитектура, настоящая ценность утечки осталась почти незамеченной. Anthropic случайно показала миру не список фич. Она показала, как на самом деле думает её ИИ‑агент.

За милыми именами и игровыми механиками скрывается жёсткая инженерная реальность: самовосстанавливающийся цикл запросов, вычисления во сне и двухуровневая система отсечения функций. Это уже не обёртка над API. Это операционная система для ИИ. И сегодня мы разберём три паттерна, которые делают Claude Code не просто дорогим автокомплитом, а продуктом на 2,5 млрд $ в год.

Еще недавно казалось, что MCP решит главную проблему ИИ-агентов: даст единый способ подключать инструменты, данные и внешние системы.

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

В последнее время мне захотелось вернуться к проекту игровой консоли. Правда, он забуксовал, но ничего страшного: это долгоиграющий проект, и буду его разбирать по чуть-чуть. А вернулся к нему всё потому, что захотелось программировать. Потом я стал размышлять, что необязательно делать свою консоль — можно достать готовую. И везде я слышал упоминания про ретро-консоли, а у меня такой не было! Выбрал для себя Anbernic RG35XX Pro и заказал.

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

Всё будет рассмотрено на примере PortMaster и написания Hello World на C/C++ (SDL2, SDL3, raylib), но также поговорим про Unity, Godot и HTML5 (Phaser).

120 миллиардов параметров, контекст 256K токенов, агентное поведение — и все это на одной видеокарте. Мы подключили Nemotron 3 Super к Luxms BI и неделю тестировали на реальных аналитических задачах. В этой статье — что получилось, где модель справляется, а где пока нет.

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

Самый модный проект 2026-го года OpenClaw от вайбкодера Питера Штейнбергера за пару месяцев набирает 336 тыс. звёзд на гитхабе, вайбкодера зачем-то берут на работу в OpenAI. Но никто не знает имени парня, написавшего движок, на котором работает этот OpenClaw.

Знакомьтесь — Марио Цехнер.

В дашборде было 83 успешных engagement’а. В аналитике X — 16 настоящих ответов. Пять к одному. Неделю я этого не замечал.

Контекст: у меня автономный AI-агент, который пишет комментарии в X (Twitter) от имени клиентов. Находит релевантные треды, генерирует ответ, публикует через браузер. Без моего участия. Ну, предполагается что без моего участия.

Привет, Хабр!

Хочу поделиться своим опытом прохождения Системного Дизайна (aka System Design) в Бигтех. От первых шагов и провалов до успешно пройденной секции. Лично мне изначально эта секция показалась попроще чем алгоритмы. В целом я до сих пор так думаю, но проще — это не значит просто. Что же кроется в мелочах? Давайте разберемся.

Недавно я выпустил две статьи - про подход POSSE и про SEO + GEO в 2026 году. В комментариях и личных сообщениях несколько человек попросили описать техническую часть.

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

Привет, Хабр! Меня зовут Андрей Горлов, я CEO IT-компании «Альтеркод» и программный эксперт курса «Python-разработчик» в Яндекс Практикуме. Недавно мы провели рефакторинг программы: добавили больше практики, обновили версии фреймворков и сделали обучение более сбалансированным для студентов.

В этом материале мы с продуктовым лидом Александром Скугаревым кратко расскажем об изменениях. Текст будет полезен тем, кто хочет узнать больше о том, как устроено онлайн-образование в IT, и всем, кто думает об обучении Python в Практикуме.

Это первая часть из задуманной серии статей про ИИ. Здесь мы на немного заступим в техническую часть памяти/контекста LLM моделей. Разберем, почему они частенько забывают или выдумывают факты и врут.

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

От вайбкодинга к профессиональной ИИ‑разработке на примере LanChess: 3300 промптов, 832 коммита, 100 тыс. строк кода и путь от POC к продакшен‑сервису.

Поздний вечер, я смотрю в терминал. Celery worker на восьмиядерном сервере перемалывает 67 партий блица на Lichess одного из пользователей. Через минуту этот человек получит персонализированную аналитику и упражнения от сервиса, аналогов которого в России найти пока не удалось. Я же сижу и думаю, стоит ли выводить этот сервис из закрытого режима по инвайтам.

Менее чем за 3 месяца я написал 100 тыс. строк кода и ни одной — своими руками. Мне пришлось стать оператором персональных данных. РКН порекомендовал мне убрать авторизацию от Google. А ВК не давал мне подключить свою авторизацию, пока я не стал самозанятым.

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

Я всю жизнь писал только бэк и подкапотщину - будь это классический КРУД, хайлоад, CLI, [вставьте свое]... И для любых сетевых взаимодействий чаще всего люди думают именно прикладными вещами - GRPC, REST, Kafka, не задумываясь об этом глубже - супер удобные инструменты с защитами от дураков и прочими радостями

Но тут спохватился я писать фронт - подключать свое же к себе же. И в этот момент я понял, насколько же это сложно, муторно и, главное, НЕУДОБНО взаимодействовать REST'ом

ЗАЧЕМ ОН НУЖЕН?? - У нас нет удобного контракта общения (eg Proto, Avro) кроме Swagger, который нужно поддерживать с обеих сторон. Да и к тому-же, сложность взаимодействия с JSONом с ОБЕИХ СТОРОН - одна постоянно маршаллит, защищается, ищет поля, в то время другая боится резких обновлений, что строчка получения поля может превратиться в что-то в роде