Обновить
1024K+

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

Искусство создания компьютерных программ

1 305,4
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Свой биллинг для ИИ-агента: микрокредиты и контроль расходов

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели5.8K

На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Сегодня разбираем, как написать биллинг для продакшн ИИ-агента.

Когда ваш ИИ-бот начинает отвечать клиентам в B2B-сегменте, каждый его ответ стоит токенов. Чтобы экономика продукта сходилась, расходы на LLM нужно жестко контролировать и тарифицировать. Кажется, что достаточно просто прикрутить калькулятор, но на деле всё сложнее: один HTTP-запрос может дергать до пяти разных нейросетей, и не все они идут через стандартный граф фреймворка.

В новой статье на Хабре рассказываю: — Почему считать деньги по чатам — это путь к хаосу. — Зачем мы изобрели «микрокредиты» вместо наивных токенов. — Как протащить контекст биллинга через пять LLM-вызовов в одном запросе с помощью магии ContextVar + Mixin.

Разбор для тех, кто делает multi-tenant LLM-сервисы и уперся в ограничения готовых прокси-решений.

Читать далее

C++101

Время на прочтение179 мин
Охват и читатели36K

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

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

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

Когда я собирал оглавление Game++, раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе.

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

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

Читать далее

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

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели9.1K

Последние полгода наблюдается дикая истерия из-за этого харнеса. Репозиторий affaan-m/ECC появился в январе 2026-го и к началу июня собрал 210 тысяч звёзд. Для сравнения, freeCodeCamp набирал свои 446 тысяч двенадцать лет. В конце марта два независимых awesome-листа почти одновременно вписали в заголовок термин «harness engineering» — будто он всегда был. На GitHub завелись «фабрики скиллов», которые обещают сгенерировать тебе команду агентов из одного абзаца. Появилось то самое неприятное чувство: не поставил себе мета-харнес — отстал от поезда.

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

Читать далее

Что aбсолютно каждый разработчик должен знать о лицензиях и Copyright

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели8.6K

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

В Axelix мы в последнее время начали получать contribution-ы извне. И как по приватным обсуждениям, так и по GitHub я могу сделать вывод, что у очень многих людей есть довольно серьёзное непонимание того, что означает та или иная лицензия, что вообще такое “Open Source” и даже что такое Copyright.

Мне кажется, что я пару вещей в этой теме немного понимаю, и я чувствую некоторую ответственность этим знанием поделиться. Поэтому я решил написать небольшую статью, которая объясняет базовые концепции в Software, начиная с Copyright и Licensing.

Позже я, возможно, ещё напишу про CLA, Open Core и про то, как AI Agents и AI в целом вписываются в эту картину. Так что, если вам интересно, дайте знать :)

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

Давайте я попробую объяснить, как вообще вся юридическая часть вокруг софта устроена, шаг за шагом.

Читать далее

Актуальный гайд на Cursor в 2026 году

Уровень сложностиПростой
Время на прочтение11 мин
Охват и читатели27K

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

К 2026-му году Cursor стал полноценной средой для кодинга без…. кодинга. Вместо этого вы оперируете ИИ-агентами и отдаете им приказы. Ручное программирование с каждым годом становится ближе к статусу «истории». Cursor является лучшим ПО для работы с агентами и вайбкодинга.

В этом гайде мы без воды рассмотрим такие аспекты программы как: интерфейс, работа с контекстом, режимы агента, модели, правила проекта, MCP, skills, hooks и др.

Актуально на лето 2026 года. На момент написания самая свежая версия — Cursor 3.6.

Поехали.

Читать далее

verified by n8n: Как мы сгенерировали ноду из OpenAPI и почему пришлось выбросить рукописную версию

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели8.6K

Привет, Хабр! Меня зовут Андрей и я развиваю портал для разработчиков в корпоративном мессенджере Пачка. Эта статья про то, как мы превратили рукописную ноду для n8n в артефакт, который генерируется из одного файла спецификации, и как она прошла официальную верификацию и встала в каталог n8n со статусом verified by n8n.

По дороге мы выбросили целиком первую версию ноды и перевели всю документацию API на новый процесс генерации. Ниже — как это устроено внутри, с кодом и граблями.

Если коротко, что получилось: правка в одном .tsp-файле автоматически расходится в документацию, CLI, SDK и n8n-ноду, а CI публикует всё по реестрам. Нода больше не может отстать от API, потому что собирается из того же источника.

Читать далее

Ошибка в коде, на которую приходится не обращать внимание

Уровень сложностиСредний
Время на прочтение5 мин
Охват и читатели10K

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

Читать далее

Создание своего языка программирования на Rust #3: Парсинг стейтментов вывода и присвоения

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели8K

Третья часть написания своего языка программирования на Rust с нуля: Парсинг первых стейтментов языка: вывод и присвоение.

Читать далее

Простые желания: разработаем максимально простой и дешевый бэкенд интернет-банкинга

Уровень сложностиПростой
Время на прочтение29 мин
Охват и читатели7K

Анализ, архитектура, вайбкодинг и даже комиксы — всё это здесь.

Цели статьи: 1) проверить жизнеспособность концепции максимально простого и дешевого интернет-банкинга и заодно 2) протестировать возможности ИИ в качестве инструмента прототипирования.

Читать далее

Бум ИИ — это твой шанс стать тем, кем ты хочешь

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели10K

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

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

Забудьте о привычном карьерном росте, который вы знали. Правила уже поменялись. Вас заменила не нейронная сеть. Вас заменили четырёхрукие сеньоры-Шивы, которые в одиночку выдают результат за целую команду.

Каково ваше место за этим столом? Давайте разбираться вместе.

Читать далее

Контекстный менеджер Python: пишем свой with и управляем ресурсами через ООП

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели7.1K

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

Чтобы не писать громоздкие и плохо читаемые конструкции try…finally, в Python используется оператор with. Однако многие разработчики применяют его исключительно как встроенный инструмент для функции open(), упуская огромный архитектурный потенциал этой конструкции.

Читать далее

Экономный ИИ. 12 способов снизить расходы (токенов/на токены)

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели12K

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

Всё так или почти так, "но есть одно но" как поётся в одной известной песне. ИИ стоит денег, и весьма немалых при текущих ценах. А про локальные модели для большинства пользователей и компаний в РФ можно забыть. Ну и в целом кажется локальные модели - это не сценарий ИИ будущего.

Соответственно, как мы платим за интернет и за свет - регулярный платёж за ИИ — то, что нам светит в будущем, а большинству уже сейчас. На текущий момент времени расход токенов - пожалуй, самое главное что-тормозит повсеместное внедрение ИИ. Полностью без оплаты конечно не обойтись (нуу почти), но существенно сократить её точно можно. Далее все методы, которые я испробовал и использую за 3 года работы. По убыванию - от самых жестких и очевидных, до самых хитрых и "технологичных".

Читать далее

Забытый мультиколор (часть 3)

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели7K

Полное руководство по аппаратному мультиколору для тех, кто не знает, что это такое и зачем он нужен.

Совместимость, алгоритмы, эффекты и градиенты

Читать далее

Ближайшие события

Тест Лавлейс: переосмысление

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели10K

Почему один из самых требовательных тестов ИИ уже, похоже, пройден

Тест Лавлейс предложили в 2001 году, чтобы закрыть слабые места более известного теста Тьюринга. Названный в честь Ады Лавлейс - одной из первых программисток, которая сомневалась в творческих способностях машин, - он быстро стал считаться одним из самых жёстких критериев машинного интеллекта. Часто его воспринимают не просто как сложный, а как принципиально непроходимый для ИИ.

Читать далее

Создание своего языка программирования на Rust #2: Парсер выражений

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели10K

Вторая часть по написанию своего языка программирования с нуля на Rust: Написание парсера для выражений.

Читать далее

Как одна кривая регулярка может «положить» ваш сервер: разбираем уязвимость ReDoS

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели9.8K

Алерты кричат о 100% загрузке CPU, API лежит, но сетевой трафик на нуле? Знакомьтесь, это ReDoS — атака, при которой безобидная строка из 30 символов и одна неоптимальная регулярка заставляют сервер уйти в вычисления на десятилетия.

В этой статье разбираем «катастрофического возврата» (backtracking) под капотом Python, пишем эксплойт для зависания собственного процессора и разбираем правила, которые спасут ваш бэкенд.

Читать далее

VARCHAR(N) в PostgreSQL: ограничение, а не экономия памяти

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели12K

varchar(255) выглядит как аккуратное ограничение и часто воспринимается как способ сэкономить место.
Но в PostgreSQL это не так: база хранит фактическую строку, а не заранее выделяет память под весь лимит.

Разбираемся, что на самом деле делает VARCHAR(N), чем он отличается от text, когда ограничение полезно, а когда просто превращается в число, которое притворяется архитектурой.

Читать далее

10 вещей, которые бы я хотел услышать в первый год работы. Опыт Java разработчика. Часть 1: не только лишь код

Время на прочтение6 мин
Охват и читатели16K

Читатели хабра, категорически вас приветствую! Я прошел путь от стажера до разработчика Java с опытом в 5+ лет. За это время было принято не мало хороших решений, но плохие тоже не отставали, о последних и возможном способе их решения я хочу рассказать, и возможно кому то это поможет не наступить на те же грабли что и я, или же менее болезненно “отодрать” их от своих ног, если вы уже попали на них.

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

Читать далее

Тайм-трекеры отвечают не на тот вопрос. Нужен локальный агент рабочего состояния

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели14K

Парадокс. Мы измеряем железо лучше, чем себя самих.

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

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

С появлением Cursor, Claude Code, Codex и других AI-агентов рабочий день стал ещё более рваным и нагруженным. Появление мультиагентных инструментов разработки только усилило проблему. Частые смены фокуса, высокая когнитивная нагрузка, переключения контекста - я понял, что нужно что-то с этим делать.

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

Почему бы мне просто не взять готовый инструмент?

Я рассуждал логически: существующие тайм-трекеры знают "сколько", но не знают "в каком состоянии"; таск-менеджеры знают "что запланировано", но не знают что "реально произошло"; помодоро-подобные решения используют одинаковый ритм к разным задачам, но не всё так однозначно; health-приложния измеряют сон, шаги, пульс, но они ничего не знают про "5 часов в IDE", "3 часа ресерча документации", "час поиска неявной ошибки"; IDE-метрики и плагины видят код, количество строк и функций, редакций, но ничего не знают о моей усталости, сделанных перерывах, переключениях, общем контексте работы;

Читать далее

Идеальный склероз в сером ящике — мой опыт в ИИ-программировании

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели8.6K

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

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

Нейросети пока не могут работать с большими проектами. Даже лучшие их образцы начинают тупить, если кода больше 40-100 кб, и галлюцинировать после 10-60 итераций одного и того же проекта (1000 циклов - это пока что грубый маркетинг). Шестьдесят итераций - это много? Если речь об автономной ИИ-разработке, то очень мало. Если о man-in-the-loop, то более-менее уже потянет.

Я выбрал такие условия:

Читать далее