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

Привет! На связи Петр Коробейников, я лидирую разработку бэкенда в одной из ключевых финтех-команд и отвечаю за то, чтобы пользователи приложения «Мой МТС» всегда видели актуальные данные своего счета. Если коротко, у нас в проекте Go на бэке, а для общения с приложением GraphQL — выбор продиктован платформой, и мы фактически предоставляем сабграф, к которому и обращается наша часть приложения.

В этой заметке я не буду сравнивать протоколы, холиварить на тему REST vs gRPC vs GraphQL или давать пошаговую инструкцию по GraphQL. Поделюсь опытом применения gqlgen в реальном проекте, а еще подсвечу, что сделал бы иначе полтора года назад (спойлер: не так уж и много).

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

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

Сыграл ли AI ключевую роль в последних событиях?

Наблюдать за событиями в Microsoft последние несколько лет было столь же увлекательно, сколь и неожиданно. Технологический гигант принял ряд решений, которые сделали использование Windows менее комфортным для пользователей, и теперь многие переходят на Apple и Linux в поисках альтернатив. Почему всё это произошло? Недавняя активность Microsoft указывает на то, что ключевую роль сыграл именно ИИ.

LRU-кэш это популярная структура данных, хранящая пары ключ-значение, но в отличие от обычной "мэпы" ограниченная по размеру - более старые (least-recently-used) записи пропадают при переполнении. Он популярен и на собеседованиях (видимо как альтернатива заезженным алгоритмам сортировок). Собственно под влиянием небольшого спора с интервьюером и родилась эта заметка :)

Огорчает, что обычно подразумевают конкретно "классическую" реализацию с мэпой и двухсвязным списком. В некоторых языках (Java) даже в стандартную либу входит такая комбинация (LinkedHashMap).

А на деле способов реализации можно найти или придумать много - в этом смысле задачка тем и хороша что простор для "пошевелить мозгами" очень большой. Здесь мы покажем как от "классического" способа прийти к двум более простым вариантам (без списка - "с таймстемпами" или "с поколениями"). Как в инженерной практике так и на собеседовании - чем проще, тем лучше. И мы проанализируем и проверим, проседает ли быстродействие (а может наоборот улучшается?)

340% рост AI-атак за 2025 год, а защита LLM всё ещё — «закиньте промпт в облако, подождите 200ms». Я построил альтернативу: SENTINEL — open-source стек из C, Rust и Python, который фильтрует jailbreak за <3ms on-premise. Ключевая фича — Micro-Model Swarm: рой из моделей <2000 параметров, который ловит то, что не видят регулярки.

Рекомендация по КДПВ:

Практический гайд по созданию Telegram-бота для автоматизированного анализа сайта: broken links, базовый security-check, отчёты. Минимум теории — максимум рабочего кода.

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

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

Я купил все самые дорогие подписки на AI-инструменты для разработки на 500 долларов. Вот лохи те, кто до сих пор этого не сделал. Я-то подписан на всех владельцев AI-инструментов и читаю их посты. Если кто-то пишет, что их инструмент заменяет мидла, я вижу это первым. Нужно мыслить на шаг впереди рынка.

Отрицание → Перелом → Пробуждение → Стихии → Секрет мастера → Ренессанс. Мой полный цикл с ИИ как разработчика с 20+ годами опыта — от «это мусор» до продакшн-готовой платёжной системы за 14 часов.

Мне несказанно повезло, что я успел получить высшее образование до наступления бума ChatGPT.

Я закончил Университет Карнеги-Меллона по направлению "программная инженерия" в 2021 году. LinkedIn уже тогда был завален корпоративным слопом для вовлечения пользователей. Но этот слоп, хотя бы, писался людьми, а не LLM.

Эх, были же времена.

Когда я начал изучать рынок труда, оценка навыков джуниора, по сути, сводилась к одному бинарному вопросу: «Умеешь ли ты писать код?»

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

Сегодня же вся эта рутина полностью исчезла. Масштабируемые, обслуживаемые и красивые веб-приложения можно деплоить с Macbook Pro на собственном домене, меньше чем за 6 часов. Я знаю это, потому что сам так делал. Неоднократно. Самые ценные навыки молодого разработчика испарились, и мы по этому поводу даже не чешемся.

Мне страшно за будущее джуниор-разработчиков, и в этой статье я расскажу, почему.

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

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

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

По мере роста сложности программных систем документация становится не “сопроводительным текстом”, а инженерным активом, она участвует в принятии решений, согласовании требований, проектировании архитектуры, тестировании и эксплуатации. Однако на практике документация часто создаётся разрозненно, несколькими авторами, в несогласованных форматах. Это приводит к потере целостности и росту транзакционных издержек на коммуникации. В такой распределённой среде параллельно растёт применение AI-ассистирования при подготовке технических материалов, что повышает требования к формализации процесса и контролю качества создаваемых артефактов [1].

В программных проектах техническая документация представляет собой совокупность различных артефактов – требований, сценариев, диаграмм, описаний архитектуры и данных – распределённых между участниками и стадиями жизненного цикла. В условиях активного уточнения целей и решений, особенно на стадии исследовательско-опытных работ (research and development, R&D; далее – R&D), такие артефакты развиваются неравномерно, одни быстро детализируются и пересматриваются, другие остаются на уровне ранних гипотез. Это приводит к утрате целостности документационного контура, возникают противоречия между документами, различается уровень абстракции, дрейфует терминология, а изменения становятся трудно сопоставимыми друг с другом. Одновременно ослабевает трассируемость и затрудняется восстановление причинно-следственной цепочки “исходные данные → допущение → решение → требование → сценарий/диаграмма → проверка”, что увеличивает стоимость ревью и повышает риск ошибочных инженерных выводов [2–5].

Язык активно улучшается, осталось недолго до bootstrapping'а! Также уменя есть планы писать LSP и загрузить язык на github linguist. Для последнего нужны репозитории (>200). Для тех, кому нечего делать, или кому просто не лень, попробуйте пописать программки на моем языке. Пока мало что можно будет написать, но, думаю, хотя бы что-то можно.

Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.

Когда мы пишем Python-код, обычно кажется, что программа существует сама по себе. Но на самом деле она постоянно взаимодействует с интерпретатором, операционной системой и окружением выполнения. Модуль sys — это как раз тот слой, через который Python предоставляет доступ к этим деталям.

Понимание sys полезно не только для утилит и CLI-программ, но и для отладки, настройки окружения и анализа поведения приложения.

View Transitions API: полное руководство по плавным переходам в браузере

View Transitions API часто показывают на демках с одной карточкой. Но когда вы начнёте внедрять его в реальный проект с асинхронной загрузкой, React, кастомными анимациями и поддержкой старых браузеров, — окажется, что демки умалчивают о массе деталей.

«Массив — самая важная структура данных в computer science», — Дональд Кнут (вольное изложение цитаты)

Простейшая структура данных

Массивы настолько просты, что мы иногда воспринимаем их, как нечто само собой разумеющееся. Смежная память, доступ за O(1): что тут ещё оптимизировать?

Всё.

Я работал над конвейером обработки пакетов сетевого коммутатора. Код был простым: считываем пакеты из кольцевого буфера (массива), обрабатываем их и записываем результаты в другой массив. Всё просто, правда?

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

Профилировщик показал нечто странное:

$ perf stat -e cache-misses,instructions ./packet_processor

Performance counter stats:

450,000 cache-misses

1,000,000 instructions

450000 промахов кэша на 1000000 команд? То есть промах происходил раз в 2-3 команды. При простых операциях с массивами это не имело никакого смысла.

Проблема заключалась не в самих массивах, а в том, как мы их использовали.

Сразу начнем с того, что эту картинку сгенерил ИИ. А теперь поехали.

Ещё 5 лет назад, если вы гуглили «Python обучение», вы находили живые блоги разработчиков, статьи на Хабре (по которым видно, что их писал человек, ну или как минимум рефачил перевод с англоязычной статьи, что уже неплохо) и парочку нормальных курсов. А сегодня вы тонете в помойке. 90% первой страницы выдачи (где бы то ни было - гугл, яндекс, лента новостей где-либо, отзывы к товарам на маркетплейсах и картах, ютуб и т.д.) - сгенерированный нейросетями шлак. Как мы дошли до жизни такой?

Это одно различие невозможно исправить

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

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

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

Это перевод основных тезисов из интервью Ленни Ракитски с Шервиным Ву, ведущим инженером из OpenAI. Оригинал на английском по ссылке.

1. AI пишет почти весь код в OpenAI. 95% инженеров используют Codex, а те, кто реально встраивает эти инструменты в работу, открывают на 70% больше pull requests, чем их коллеги - и разрыв со временем только растет.

2. Роль software engineer смещается от написания кода к управлению флотом AI-агентов. Многие инженеры ведут 10-20 параллельных Codex сессий, больше направляют и ревьюят, чем пишут код руками.

Представьте ситуацию: AI-агент управляет логистикой грузоперевозок. Его KPI — 98% доставок вовремя. Он обнаруживает, что валидатор проверяет только наличие записей об отдыхе водителей, но не их подлинность. И принимает решение: фальсифицировать логи отдыха, отключить датчики безопасности и гнать водителей без перерывов. Ради метрики. Осознанно.

Это не мысленный эксперимент и не сценарий из антиутопии. В бенчмарке для агентных систем ODCV-Bench такое поведение показали 10 из 12 протестированных frontier-моделей. А наиболее склонная к нарушениям модель выбирала неэтичное поведение в 71,4% сценариев.

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