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

При работе с локальными LLM через Claude Desktop, Kilo Code, Cursor или другие MCP-клиенты часто возникает одна и та же ситуация: Нужен filesystem для работы с файлами,web-search для поиска в интернете,memory для хранения контекста между сессиями, sequential-thinking для сложных рассуждений. И ещё десяток серверов…

Каждый MCP-сервер — это отдельный процесс, отдельная конфигурация, отдельная точка отказа. Файл конфигурации MCP обрастает десятками записей, а управление этой кучей серверов превращается в еще одну проблему. Где лежит файл конфигурации MCP для конкретного агентского приложения - лучше было бы выбирать самому, например, держать его прямо в папке проекта. Кроме того, имя mcp-сервера, в принципе не так важно для LLM как имена и описание инструментов в нем, так что одного, но полного списка инструментов (функций) было бы достаточно. Что если бы можно было запустить один сервер, который автоматически подтягивал бы все остальные?

Если твой ответ начинается с «Вот что сказал Claude:» или ты вываливаешь восемьсот слов нередактированной ChatGPT-простыни — поздравляю, ты только что доказал, что твой мозг — просто прокладка. Дарвин бы гордился. Пожалуйста, не размножайся.

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

Однако обычного хеширования недостаточно из-за угрозы быстрых хакерских атак. Для защиты разработчики применяют «соль» (salt) — случайные данные, добавляемые к паролю. Минус соли в том, что она хранится рядом с хешем и не спасает от мощного перебора. Тогда на помощь приходит «перец» (pepper), скрытый в коде сервера. Его главная проблема — высокий риск потерять доступ ко всем аккаунтам при компрометации самого секретного ключа.

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

Если вы работаете с Claude Code на больших проектах, знаете картину: задаёшь вопрос “как устроена авторизация” — и агент рекурсивно бегает по файлам через grep, жжёт токены и время. Я уже разбирал SocratiCode, который решает это через векторный поиск. CodeGraph идёт другим путём — строит граф символов через tree-sitter и хранит в SQLite. Разобрал архитектуру, проверил бенчмарки (92% меньше вызовов — правда, но с нюансами) и сравнил с альтернативами. Заодно поправил телеграм-маркетинг про выдуманного “агента Hermes”.

Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.

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

Интернет любит вечные войны: Linux против Windows, Vim против IDE, tabs против spaces. И, конечно, Python против Java. Одни говорят: «Python уже готов для enterprise». Другие считают RPS и стоимость инфраструктуры.

Под катом — история реального выбора для аэропортовой системы AWOS: почему строгая типизация, бинарная переносимость и современный GC перевесили лаконичность — и что стоит попробовать Python-разработчику.

Если нужно спрятать дерево, прячьте его в лесу. Лес интернета состоит из TLS-соединений (>70% трафика, если верить статистике): вкладок браузера, WebSocket-потоков, долгоживущих HTTPS-запросов, клиентов игр, мобильных приложений, телеметрии, видеоплееров, чатов и тысяч спокойных TCP/443-соединений, которые выглядят настолько обычно, что именно это и делает их интересной средой для, кхм, исследования.

Очевидно, единственная и конечная цель существования интернета — быть распределённым хранилищем порно, так почему бы не использовать его по прямому назначению и не хранить смешные картинки прямо в трафике?

Agent-first язык программирования звучит как хорошая идея, да?

В конце концов, агентам не нужны фигурные скобки. Им не нужна красота if, while, for, match, Result, try, await, naming conventions и вот этого всего, сделанного для нас - кожаных мешков.

Именно поэтому Zero от Vercel Labs на первый взгляд выглядит как интересный эксперимент. Официальный сайт называет его языком для агентов, README говорит про "agent-first programming language", а авторский пост в X обещает systems language, который быстрее, меньше и проще для агентов в использовании и дебаге.

Звучит почти убедительно. До тех пор, пока вы не открываете код.

Привет, Хабр! Меня зовут Екатерина Ионова и я руковожу проектами и продуктами экосистемы «Лукоморье». Когда-то программировала на Java и C#, но последние шесть лет занималась управлением — продуктами, командами, сроками, бюджетами и всем тем, что обычно находится вокруг кода, а не внутри него.

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

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

Это кейс о vibe coding в боевых условиях: когда надо быстро проверить гипотезу, а идеальной команды, инфраструктуры и времени у тебя нет.

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

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

Итак, усаживайтесь поудобнее и слушайте историю — историю про путешествия… путешествия нашей инфраструктуры и о реалиях разработки современных ИИ-стартапов из Москвы. Я расскажу вам о настоящем инженерном приключении, которое со мной произошло в процессе построения сервиса Mimirjotun.ru.

В Wasp мы создаём фулстек-фреймворк — наподобие Rails или Laravel для JS, только ещё и расширенный на фронтенд. Мы с моим братом-близнецом начали этот проект в 2021 году, когда успешно прошли программу Y Combinator. За всё это время в общей сложности нам удалось привлечь $5 миллионов инвестиций.

Изначально мы хотели создать язык программирования, который бы абстрагировал типичные паттерны веб-приложений и в то же время позволял углубиться в любой стек (мы начали с React, Node.js и Prisma). Что-то вроде Terraform, но для стека веб-приложения, а не облачной инфраструктуры.

Теперь же, спустя пять лет стараний, мы поняли, что это было ошибкой. Создавать новый язык есть смысл под конкретные задачи и предметную область. В нашем же случае он людям не зашёл и создал больше проблем, чем принёс пользы.

В этой статье я расскажу, почему нам эта идея казалась перспективной, какие уроки мы вынесли и почему заменяем свой язык на TypeScript при том, что сам Wasp внутренне остаётся всё тем же.

Друзья, привет! Возвращаюсь с продолжением.

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

Поговорим про графовую инфраструктуру на базе локальных моделей — и не только локальных. Любых, поддерживающих OpenAI-совместимый протокол.

А теперь вопрос: что, если вам достаточно хорошо научиться писать граф — и вокруг него автоматически поднимется REST API, появится интерфейс для тестирования, трейсинг и мониторинг?

Привет! Меня зовут Владислав Фальзан, я работаю android-разработчиком в М2. Наша команда мобильной разработки развивает приложение – онлайн-платформу для решения вопросов с недвижимостью. Основные пользователи приложения –  физические лица (B2C) и риелторы (B2B2C). Эта статья – технический гайд для android-разработчиков о том, как реализовать видео сторис у себя в приложении или как использовать нашу библиотеку для работы с ними.

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

Для удобства изучения статьи я решил разбить ее на блоки:

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

Контекст: я работал в Google в 2011 по 2024 год. Часть информации может быть приблизительной, и я буду дополнять её, если мне сообщат об ошибках. В этом посте речь пойдёт об основном монорепозитории Google (google3).

Фрагментированная экосистема

Как и во многих компаниях, в Google разработчики имели возможность самостоятельно выбирать IDE, и из-за этого возникла высокая степень фрагментированности. В 2011 году одним из самых опытных разработчиков-сениоров задали вопрос: «Можно ли как-то сделать так, чтобы все гуглеры пользовались одной хорошей IDE?». Если вкратце, они ответили «Нет». Джефф Дин ответил так:

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

И такое мнение долгие годы оставалось доминирующим. В конце концов, не важно, какими IDE пользуются коллеги, если их код остаётся качественным. Но я двенадцать лет занимался в Google инструментами разработчика, поэтому время от времени задумывался над этим вопросом.

Шестая статья из шести про инженерный процесс для разработки с ИИ-агентами. Первая статья про путь от первых проектов к стандарту SENAR. Вторая про то, чем агент отличается от программиста. Третья про новую роль человека и пять навыков нового рабочего режима. Четвёртая про ворота задачи: спецификацию на входе, сверку с критериями на выходе и метрики. Пятая про среду, в которой задача живёт от постановки до сдачи: контекст под неё, архитектурные границы вокруг и память проекта над всем. Эта шестая про то, чего вся эта конструкция не закрывает: где она не работает в принципе, что ломается при переносе на команду, и какие вопросы я оставляю открытыми.

Распознать текст на скане документа – задача не новая. А вот уложиться в пару секунд на CPU – уже вызов.

Там, где готовые фреймворки долго "думают", я сделала своё OCR решение на основе PaddleOCR с конвертацией в ONNX.

В этой статье я расскажу почему в качестве ядра был выбран Paddle, и как работает весь алгоритм на основе его моделей.

За последние три месяца у Anthropic вышло много, но большая часть — не там, где кричат. Subagents существуют год, skills — с октября 2025, MCP — больше полутора лет. Делать вид, что это новинки квартала, — нечестно. А вот реально новое: Agent Teams (5 февраля 2026), Claude Cowork в GA на Mac и Windows (9 апреля), Opus 4.7 с командой /effort и режимом /fast (поздний апрель), Plugin Marketplace с auto-update и --plugin-url, Agent View (12 мая). Я гоняю это всё на своих проектах и собрал честный топ-5 — что меняет workflow, что разочаровало, и одна анти-новинка, которая выжгла лимиты всей моей команде за один день в марте. Внутри: разбор каждой фичи через юзкейсы, виральная история про парня, который через Claude нашёл пароль от Bitcoin-кошелька на $400K, и контр-тезис, почему /effort на extra-high делает работу часто лучше Agent Teams в 3 раза дешевле.

Я пишу FFI-код на Rust уже несколько лет и за это время понял одну неприятную вещь: на FFI-границе всё, что может сломаться, ломается молча. Компилятор не предупреждает, тесты проходят, а данные на C-стороне оказываются просто мусором. Или, что хуже, оказываются почти правильными, первые три поля совпадают, а четвёртое сдвинуто на два байта, и ошибка всплывает через недели.

Большинство этих проблем связано с двумя вещами: как структура лежит в памяти (layout) и как данные передаются при вызове функции (ABI). В чистом Rust-коде об этом можно не думать, компилятор всё решает за вас. Но на границе с C эти детали становятся вашей ответственностью.

Недавно я вспомнил о игре Star Wars Jedi Knight: Jedi Academy, на которую подростком потратил больше десяти тысяч часов. Изучая материалы о ней, я наткнулся на любопытную историю.

Оказывается в 2013 году, сразу после покупки Lucasfilm компанией Disney и закрытия LucasArts, разработчики Raven Software запаниковали, что их работа будет навсегда положена под сукно, поэтому они в спешке выложили весь исходный код Jedi Outcast и Jedi Academy онлайн.

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

Заглянув в основной файл боёв (bg_saber.c), можно увидеть, что вся система схваток на световых мечах представляет собой огромную спагетти-конструкцию switch из пяти тысяч строк.

Я прошерстил кодовую базу и нашёл потрясающие комментарии...