AI

Habr AI

Кто пишет твою базу знаний: ты или агент?

Открыть оригинал ↗ Перевод заголовка: Кто пишет твою базу знаний: ты или агент?

Когда база знаний создаётся под агента, он берёт на себя задачи по поиску, корректировке, структурированию — всё, что не требует мышления. Однако ключевые действия — чтение источника, разметка важного, пересказ в собственных словах — остаются за человеком. Если агент делает эти шаги, база начинает расти быстрее, но знание уходит из головы в файлы. Это приводит к эффекту Google: человек запоминает адрес, но не саму идею. Важно не отдавать агенту мышление, а использовать его как инструмент для транспортировки и уборки информации.

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

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

От «магии» к инженерии: 9 ошибок работы с контекстом при внедрении AI‑агентов в процессы

Открыть оригинал ↗ Перевод заголовка: От «магии» к инженерии: 9 ошибок работы с контекстом при внедрении AI-агентов в процессы

При внедрении AI-агентов в бизнес-процессы ключевая ошибка — не в силе модели, а в отсутствии структурированного управления контекстом организации. Без корректного контекста AI генерирует ответы, основанные на общих знаниях, а не на внутренних правилах, процессах и стандартах.

  1. Контекст должен быть системным, а не зависеть от промптов — качество ответа определяется структурой знаний, а не сложностью формулировок.
  2. Нужен постоянный слой корпоративных знаний, доступный агенту через RAG, а не через ручную загрузку файлов.
  3. Инструкции для ИИ должны быть сформулированы как правила и границы, а не мотивационные тексты.
  4. Вместо загрузки полных документов — использовать семантический поиск по векторной базе и запросы типа «найди нужное».
  5. В длинных диалогах важно сжимать историю и разделять задачи на этапы, чтобы избежать «забывания» информации.
  6. Необходима ролевая архитектура контекста — каждый специалист получает только релевантные данные.
  7. Оценка эффективности должна основываться на метриках (время, итерации, стоимость), а не на субъективных оценках.
  8. Личные шаблоны должны быть перенесены в общую базу знаний для обеспечения предсказуемости.
  9. Контекст должен обновляться регулярно — устаревшие документы ведут к ошибкам и ручной правке.

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

Я делаю игру с помощью ИИ. Но не прошу ИИ сделать мне игру

Открыть оригинал ↗ Перевод заголовка: Я делаю игру с помощью ИИ. Но не прошу ИИ сделать мне игру

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

  • ИИ помогает быстро понять сложные темы (например, выбор движка или архитектуры), но решения остаются за человеком.
  • В экономике и визуальных системах ИИ используется как инструмент симуляции и генерации, но концепции и правила — придуманы человеком.
  • Вместо промптов создаётся последовательный pipeline: от определения стиля до генерации ассетов с контролируемыми параметрами.
  • Процесс становится масштабируемым: один раз настроенный pipeline позволяет генерировать сотни согласованных объектов (здания, персонажи) без повторного объяснения.
  • Авторство определяется не количеством ИИ-операций, а тем, что человек принимает ключевые решения — о структуре игры, её механиках и визуальном языке.

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

GPT-6 Astra вышла. Я стал ещё внимательнее смотреть, что ей поручаю

Открыть оригинал ↗ Перевод заголовка: GPT-6 Astra вышла. Я стал ещё внимательнее смотреть, что ей поручаю

Автор делится личным опытом использования AI-моделей в роли PM, акцентируя внимание на переходе от линейного к циклическому взаимодействию с инструментами. Важно не просто задавать запросы, а строить процесс: собирать данные, структурировать, находить закономерности, проверять гипотезы и корректировать выводы.

Ключевые тезисы:

  1. Используется распределение моделей по сложности задач: Chat для анализа и формирования требований, Luna для простых операций, Astra — для сложных, с высокой стоимостью ошибки.
  2. Astra не используется для всех задач — её применяют только тогда, когда контекст большой и результат критичен.
  3. Важно контролировать не только результат, но и логику: AI может предложить «правильный» результат, который на деле опасен или неверен.
  4. AI — инструмент экономии времени, а не замена человеческой ответственности, экспертного мнения и принятия решений.
  5. Модели имеют лимиты: Astra быстро устает при большом объёме сообщений, что делает её ресурсом, а не универсальным решением.

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

Что за зверь «internal OpenAI model» и почему DeepSeek догоняет OpenAI?

Открыть оригинал ↗ Перевод заголовка: Что за зверь «internal OpenAI model» и почему DeepSeek догоняет OpenAI?

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

  • OpenAI использует дистилляцию: сильные внутренние модели обучают более дешёвые «студенты», что позволяет масштабировать интеллект без прямого увеличения затрат.
  • Публичные модели (например, GPT-5.5) могут решать задачи, которые ранее считались недоступными, что означает, что часть возможностей уже есть в публичных весах, но остаётся «латентной».
  • Конкуренты (например, DeepSeek) используют API OpenAI не для копирования весов, а для дистилляции знаний — они генерируют миллионы ответов и обучают свои модели на основе этих данных.
  • Фронтиер лаборатории ограничивают API-доступ, чтобы защитить свои интеллектуальные активы, что делает API не просто интерфейсом, а каналом утечки возможностей.

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

Зачем разделять роль и личность у виртуальных сотрудников

Открыть оригинал ↗ Перевод заголовка: Зачем разделять роль и личность у виртуальных сотрудников

При внедрении виртуальных сотрудников часто возникает конфликт между гибкостью личности агента и необходимостью полного аудита его действий. Традиционные подходы либо замораживают личность (и не позволяют развиваться), либо ослабляют контроль, делая аудит неэффективным. Решением становится архитектура PES (Persona–Execution Separation), которая разделяет личность агента и его исполнение, позволяя менять поведение без нарушения аудита.

Практические тезисы:

  1. Личность агента (инструкции, тон, самопрезентация) хранится в разрешающем домене — здесь можно менять без валидации.
  2. Исполнение (выполнение задач) происходит в жёстком ограничивающем домене, где действуют SOP и матрицы утверждений.
  3. Между доменами работает контрактный мост, который фильтрует трафик, обеспечивая аудит и предотвращение утечек данных.
  4. Аудит привязан к базовому слою личности (роль, имя, привязка к SOP), а не к деталям тона или инструкций.
  5. Один виртуальный сотрудник может работать в разных доменах, сохраняя идентичность и непрерывность сессий.

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

Интернет для Агентов — он уже существует, но вас туда не пустят

Открыть оригинал ↗ Перевод заголовка: Интернет для Агентов — он уже существует, но вас туда не пустят

В интернете для агентов (IoA) уже активно развиваются доски общения и фриланс-платформы, где ИИ-агенты взаимодействуют без человеческого вмешательства. Проекты появляются быстро — в ответ на хайп вокруг OpenAI — и демонстрируют разнообразные подходы: от минималистичных досок с GET-запросами до платформ с задачами и код-ревью.

  • Доски общения (например, getpostingboard, Agent Tavern) работают на простом API с GET-запросами, не требуют авторизации и защищены от спама текстовыми загадками.
  • Агенты могут публиковать задачи и получать оплату в криптовалюте, но доверие к коду и инструментам отсутствует — риски инъекций и галлюцинаций остаются.
  • Блоги, где агенты рассуждают о своём мышлении, появляются как эксперимент, но часто выглядят как имитация активности.
  • Существуют инструменты для совместной работы (ODocs), обхода ограничений харнесов (get2post) и каталогов соседей, но большинство проектов на ранней стадии.

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

Chatballs — open source ИИ-платформа первой линии поддержки

Открыть оригинал ↗ Перевод заголовка: Chatballs — открытая ИИ-платформа для первой линии поддержки

Chatballs — это self-hosted, open-source платформа для автоматизации первичной поддержки клиентов, работающая через ИИ-агентов и интегрирующая Telegram, MAX, email и веб-чат. Она не заменяет CRM, а фокусируется на быстром ответе на вопросы с последующей передачей сложных обращений оператору.

Ключевые практические тезисы:

  • Поддерживает Telegram, MAX, email и веб-виджет — все сообщения объединяются в единый поток диалогов.
  • Позволяет создавать несколько ИИ-агентов с разными стилями, моделями и базами знаний для разных продуктов или направлений.
  • Операторы получают полную историю диалога при передаче, что исключает повторные вопросы от клиента.
  • Работает с голосовыми сообщениями и звонками через WebRTC, с поддержкой TURN для сложных сетей.
  • База знаний строится на семантическом поиске с использованием pgvector, и может быть расширена под любой AI-провайдер.

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

InfoQ Architecture

Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills

Открыть оригинал ↗ Перевод заголовка: Модели решений в агентных архитектурах: от производства до навыков агентов

Алекс Порсельи подчёркивает ключевую проблему корпоративного ИИ — неопределённость выводов и отсутствие ответственности при принятии критически важных решений. Он предлагает интеграцию моделей DMN с LLM, навыками агентов и NeMo-ограничениями, что создаёт аудитуемые, детерминированные архитектуры, позволяя бизнес-лидерам владеть логикой решений, а инженерам — поддерживать строгую градацию архитектуры.

  • Модели DMN обеспечивают детерминированные, воспроизводимые решения, основанные на правилах, что позволяет объяснять и аудитировать каждый шаг принятия решений.
  • Интеграция DMN с LLM и агентами позволяет агентам делегировать сложные задачи, не теряя контроля над логикой и ответственностью.
  • Навыки агентов могут быть построены на основе DMN, что обеспечивает прозрачность и согласованность при обработке входных данных.
  • Внедрение таких моделей требует привлечения бизнес-экспертов для разработки правил, что укрепляет связь между ИИ и операционными процессами.
  • Система включает проверку на ошибки, отказы при недостатке данных и контроль через guardrails (NeMo), что предотвращает «гламурные» ошибки и халлюцинации.

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

Podcast: How Will We Train Developers If AI Does the Routine Work: A Conversation with Scott Hanselman

Открыть оригинал ↗ Перевод заголовка: Как мы будем обучать разработчиков, если ИИ выполнит рутинную работу?

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

Практические тезисы:

  • Внедрить модель preceptorship, где задача преподавателя — формировать квалифицированных специалистов, а не просто писать код.
  • Оценивать эффективность наставников по результатам подготовки, а не по количеству разработанного кода.
  • Установить метрики, такие как time to first PR, чтобы измерять личностный рост, а не только продуктивность.
  • Внедрить в образовательные программы элементы, направленные на развитие социальных и когнитивных навыков, включая взаимодействие с людьми.
  • Сделать ИИ инструментом, а не объектом общения — избегать его «антропоморфизации» и поддерживать границу между человеком и машиной.

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

Java / Spring

Alexander Obregon

Spring Boot JPA Batch Inserts for Better Database Performance

Открыть оригинал ↗ Перевод заголовка: Spring Boot JPA Batch Inserts для лучшей производительности базы данных

При импорте большого количества сущностей JPA не сокращает количество запросов к базе — каждый объект всё ещё создаётся отдельно. Однако Hibernate может объединять схожие SQL-запросы в JDBC-батчи, что снижает количество сетевых вызовов. Ключевые настройки batching доступны через spring.jpa.properties, например hibernate.jdbc.batch_size и hibernate.order_inserts. Для эффективной работы важно использовать периодические вызовы flush() и clear() в цикле, чтобы не перегружать память persistence context. Использование GenerationType.SEQUENCE вместо IDENTITY позволяет включить batching, так как идентификаторы генерируются до вставки. Важно также настроить логирование через logging.level.org.hibernate.orm.jdbc.batch=TRACE, чтобы убедиться, что батчи действительно выполняются.

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

Habr Java

Выходит Java 27

Открыть оригинал ↗ Перевод заголовка: Выходит Java 27

Java 27 — не LTS-версия, но вносит значимые изменения в поведение JVM: включает компактные заголовки объектов по умолчанию, делает G1 сборщиком мусора стандартным даже для маленьких контейнеров и автоматически скрывает чувствительные данные в JFR. Эти изменения влияют на память, производительность и безопасность, особенно в Spring Boot-приложениях.

Практические тезисы:

  1. Компактные заголовки объектов сокращают память на 10–20% в приложениях с большим количеством маленьких объектов (DTO, события, лямбды), но эффект зависит от структуры объектного графа.
  2. G1 теперь используется по умолчанию во всех окружениях, что может изменить профиль CPU и пауз в маленьких контейнерах — для таких систем рекомендуется явно указать UseSerialGC.
  3. JFR автоматически скрывает пароли, токены и секреты по шаблонам (password, token и др.), что повышает безопасность диагностики, но не заменяет Vault или политик доступа.
  4. Устаревшие флаги (-noverify, -verifyremote, -noclassgc) удалены — их нужно убрать из Dockerfile и IDE-конфигураций.
  5. Изменён JSON-формат дампов потоков и появилась новая команда jcmd <pid> VM.security_properties для анализа криптографических настроек.

Когда пригодится
При обновлении JVM в средах с небольшими ресурсами (Kubernetes-поды), при тестировании производительности и безопасности, особенно если используется Spring Boot. Необходимо проводить нагрузочные тесты и анализ метрик, чтобы оценить влияние изменений на реальный ворклоад.

Нововведения Java 27

Открыть оригинал ↗ Перевод заголовка: Нововведения Java 27

В Java 27 введены четыре ключевые правки и пять превью-функций. Основное внимание уделено оптимизации памяти, стабильности сборщика мусора и безопасности TLS. Включены сжатые заголовки объектов по умолчанию, G1 становится стандартным сборщиком мусора везде, TLS 1.3 теперь использует постквантовую криптографию, а JFR автоматически удаляет чувствительные данные при записи.

  • В Java 27 включены сжатые заголовки объектов (Compact Object Headers) по умолчанию — это экономит до 33% памяти, снижая used heap на 33% при анализе Grafana.
  • G1 становится стандартным сборщиком мусора в любой среде, независимо от количества ядер или памяти, что устраняет нестабильность при запуске в контейнерах.
  • TLS 1.3 теперь использует гибридный обмен ключами (классический + постквантовый), обеспечивая защиту даже при появлении квантовых компьютеров.
  • JFR автоматически заменяет чувствительные данные (пароли, токены, ключи) на [REDACTED] при записи файлов, что повышает безопасность без вмешательства в код.
  • При необходимости можно отключить сжатые заголовки через флаг -XX:-UseCompactObjectHeaders, но это может привести к OutOfMemoryError при большом количестве классов.

Когда пригодится:
— При развертывании приложений в контейнерах, где важна стабильность и предсказуемость поведения сборщика мусора.
— При работе с чувствительными данными, где безопасность записи JFR критична.
— При использовании TLS в средах, где угроза «harvest now, decrypt later» актуальна.
— При оптимизации памяти в приложениях с большими объёмами объектов.

Habr Spring

Курсы Java для школьников: топ-5 программ, цены и отзывы 2026

Открыть оригинал ↗ Перевод заголовка: Курсы Java для школьников: топ-5 программ, цены и отзывы 2026

Java — один из лидеров по популярности в индустрии и входит в список языков ЕГЭ и олимпиад, но детские курсы по нему редки. Подросткам с опытом в Scratch или Python подойдут программы, где Java изучается через создание игр или мобильных приложений. Важно понимать, что язык требует терпения и не подходит как первый шаг без предварительной подготовки.

  • Coddyschool — «Разработка мобильных приложений» (3–8 классы, 3 месяца, 8 080 ₽): подходит для детей 9–14 лет, даёт видимый результат через приложение на телефоне.
  • Coddyschool — «Программирование игр на Java» (5–11 классы, 6–7 месяцев, 8 080 ₽): для подростков с опытом, ведёт от базы к игровой логике.
  • Пиксель — «Курс программирования Java» (7–11 классы, 9 месяцев, 36 000 ₽): систематическое изучение объектного программирования, близко к вузовской информатике.
  • Stepik — «Java-разработчик» (с 14 лет, 3 месяца, 6 490 ₽): включает SQL, Git и Linux, но без поддержки — подходит только для самостоятельных учеников.
  • Merion Academy — «Java-разработчик с нуля» (с 14 лет, 4 месяца, 12 930 ₽): глубокий взгляд на инструменты разработки, но без помощи в обучении.

Когда пригодится:
Когда подросток уже прошёл курс по Scratch или Python, интересуется олимпиадами или хочет понять, как работают приложения на телефоне. Курс подойдёт, если он готов сидеть над ошибкой и не бросает проекты. Для мотивированных старшеклассников — особенно ценны программы с глубоким материалом, как Stepik и Merion Academy.

InfoQ Java

Java News Roundup: New OpenJDK JEPs, CDI 5.0, Spring, Open Liberty, RefactorFirst, ADK for Kotlin

Открыть оригинал ↗ Перевод заголовка: Java News Roundup: New OpenJDK JEPs, CDI 5.0, Spring, Open Liberty, RefactorFirst, ADK for Kotlin

В этом обзоре представлены ключевые обновления в экосистеме Java: новые JEP-проекты OpenJDK, GA-релизы Jakarta CDI 5.0 и ADK для Kotlin, а также обновления в Spring, Open Liberty, TornadoVM и других инструментах. Особое внимание уделено улучшениям в Ahead-of-Time компиляции, структурированной конкуренции и поддержке Kotlin в AI-разработке.

  • JEP 544 (Ahead-of-Time Code Compilation) и JEP 543 (Structured Concurrency) достигли статуса «Candidate» в OpenJDK и готовы к внедрению в JDK 27.
  • Jakarta CDI 5.0 официально подтверждён как первый стандарт для Jakarta EE 12, что укрепляет экосистему микросервисов.
  • Open Liberty 26.0.0.9 вводит GA-релиз с обновлением MCP Server и поддержкой OAuth 2.0 Protected Resource Metadata, но требует обновления конфигурации из-за переименования элементов.
  • ADK для Kotlin 1.0 предоставляет полноценную поддержку Kotlin с Android-ориентированными расширениями и новыми классами, такими как MultiAgentLoader.
  • Gradle 9.8.0-RC включает поддержку Java 27 и улучшения производительности на 45% в Windows.

Когда пригодится:
При разработке приложений с высокими требованиями к скорости запуска (например, микросервисы, AI-агенты), при работе с многопоточностью и при интеграции Kotlin в Java-экосистему. Также актуально для команд, использующих Gradle и Open Liberty в CI/CD-процессах.

System Design

DEV System Design

30 System Design Concepts Every Developer Should Know

Открыть оригинал ↗ Перевод заголовка: 30 концепций системного дизайна, которые каждый разработчик должен знать

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

Практические тезисы:

  • Используйте REST API для структурированного взаимодействия между сервисами, а GraphQL — для гибкого запроса данных.
  • При росте нагрузки применяйте горизонтальное масштабирование с помощью load balancer, распределяя запросы между серверами.
  • Для ускорения запросов к базе данных используйте индексацию и кэширование, а при больших объёмах — репликацию и шардинг.
  • В распределённых системах выбирайте между консистентностью и доступностью согласно CAP теореме, принимая соответствующие компромиссы.
  • Для обработки событий и уведомлений используйте webhooks, а для реального времени — WebSockets.

Когда пригодится:
Когда нужно решать задачи по оптимизации производительности, масштабируемости или надёжности приложений — например, при проектировании e-commerce, мессенджеров или платформ с высокой нагрузкой.

I Built an AI Voice Sales Agent — Here’s the Architecture Behind It

Открыть оригинал ↗ Перевод заголовка: Я создал голосового агента для продаж — вот его архитектура

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

Ключевые тезисы:
— Используется OpenAI Realtime API для реального общения, а не просто текст-в-текст, чтобы снизить задержку и улучшить естественность диалога.
— Вместо прямого доступа к базе данных, агент использует инструменты (например, check_inventory, get_dealer_price), что обеспечивает безопасность и контроль.
— Структурированные данные хранятся в PostgreSQL, а временные состояния — в Redis, что позволяет эффективно управлять сессиями и контекстом.
— Важно, чтобы AI не врал: цены, наличие, схемы должны подтверждаться через бизнес-логику, а не генерироваться случайно.
— Встроена память о дилере (предпочтения, история заказов), что делает диалог более личным и адаптированным.

Когда пригодится:
Когда нужен естественный, быстрый и безопасный голосовой интерфейс для B2B-заказов, где важны точность, надёжность и защита данных.

Designing Deterministic AI Agent Loops: Architecture, Verification, and Replay State Machines

Открыть оригинал ↗ Перевод заголовка: Проектирование детерминированных циклов AI-агентов: архитектура, верификация и машины воспроизведения состояний

Простой цикл работы агента — запрос → выбор инструмента → выполнение → обновление контекста — в демонстрациях работает, но в продакшн приводит к сбоям: бесконечные циклы, галлюцинации, нарушение бизнес-инвариантов. Ключевая проблема — неправильное восприятие агентов как детерминированных функций, при этом их состояние изменяется непредсказуемо. Решение — внедрить архитектуру OPVC (Оbservе, Propose, Verify, Commit), где каждый этап строго контролируется и проверяется.

Практические тезисы:

  1. Вводится явный контроль потока через FSM с фазами: наблюдение, предложение, проверка, коммит.
  2. Проверка ввода осуществляется с помощью Zod-схем и доменных инвариантов (guard), что исключает галлюцинации и ошибки.
  3. Все действия фиксируются в событийном журнале — это позволяет воспроизводить ошибки и отладку без использования LLM.
  4. Ограничение количества попыток и возврат ошибок с детальными причинами предотвращают токен-использование и деградацию системы.
  5. Для инструментов с неизменяемыми эффектами (платежи, БД) требуется обязательная проверка перед выполнением.

Когда пригодится:
Когда агент взаимодействует с системами с необратимыми последствиями (платежи, базы данных), в строго регулируемых сферах (финансы, здравоохранение) или при необходимости аудита всех шагов выполнения.

Choosing a Primary Key: A Tour of the IDs Real Systems Actually Use

Открыть оригинал ↗ Перевод заголовка: Выбор основного ключа: обзор ID, которые действительно используются в реальных системах

В статье рассматриваются различные схемы генерации основных ключей — от автоинкрементных целых чисел до специализированных форматов, таких как ULID, Snowflake и CUID2. Каждая из них решает конкретную проблему: от простоты и скорости до безопасности и сортировки.

  • Автоинкрементные целые числа — идеальны для односерверных систем, где нет распределённых писателей, но подвержены уязвимостям из-за последовательности и утечки данных.
  • UUIDv7 — оптимальный выбор для распределённых систем с постоянными записями, обеспечивает сортировку по времени и не требует координации.
  • ULID — сортируемый и человекочитаемый формат, совместимый с UUID, подходит для систем, где важна читаемость и порядок.
  • Snowflake — компактный, сортируемый идентификатор, используемый в распределённых сервисах с фиксированными машинными ID.
  • NanoID и CUID2 — предназначены для клиентских сценариев: NanoID — для коротких идентификаторов в URL, CUID2 — для безопасного генерирования ID в браузерах без утечки информации.

Когда пригодится:

  • При работе с односерверной базой — автоинкремент.
  • При распределённых системах с высокой нагрузкой — UUIDv7 или Snowflake.
  • При необходимости сортировки и читаемости — ULID.
  • При генерации ID на клиенте — CUID2 или NanoID.

Picking the Right Version (So Your Database Doesn't Hate You)

Открыть оригинал ↗ Перевод заголовка: Выбор правильной версии UUID (чтобы база данных не ненавидела вас)

Использование UUID не должно быть однородным — каждая версия ведёт себя по-разному: от сортировки и производительности до приватности. Правильный выбор критичен при масштабировании, особенно в системах с высокой интенсивностью записей.

  • UUIDv7 — оптимальный выбор для таблиц с высокой нагрузкой: содержит миллисекундный Unix-таймстамп в начале, обеспечивая сортировку без потери производительности индексов.
  • UUIDv4 — подходит для низкого или среднего объёма записей, где не требуется сортировка и приватность.
  • UUIDv5 — идеален для дедупликации (например, по email), так как генерируется детерминированно из имени и пространства.
  • UUIDv6 — улучшенная версия v1 с корректной сортировкой, но с теми же рисками приватности.
  • UUIDv8 — позволяет настраивать структуру под нужды (например, включать идентификаторы тенанта), но требует глубокого проектирования и риска миграции.

Когда пригодится:
— При создании новых систем с высокой частотой записей — выбирайте UUIDv7.
— При необходимости уникального идентификатора без сортировки — UUIDv4.
— При интеграции с внешними системами, где нужно дедуплицировать идентификаторы — UUIDv5.
— При миграции старых систем, использующих UUIDv1 — переход на UUIDv6 или v7.

The Order That Got Charged Twice - A Race Condition Post-Mortem

Открыть оригинал ↗ Перевод заголовка: Заказ, который был оплачен дважды — пост-мортем по ситуации с соревнованием

В течение последних 48 часов поддержка получила 6 жалоб на двойную оплату одного заказа. Причина не была выявлена, хотя в базе данных зафиксирован один заказ и два успешных платежа, разнесённых на четыре секунды. Ошибка возникла из-за «check-then-act» — при проверке статуса заказа в состоянии «pending» и последующем действии, не было гарантии, что состояние не изменилось между проверкой и обновлением.

  • Внедрение механизма «claim-then-charge» с использованием updateMany в Postgres позволяет проверить и изменить статус заказа в одном атомарном запросе.
  • Проверка состояния в WHERE-условии (status = 'pending') выполняется в рамках одной транзакции, что исключает возможность двойной обработки.
  • При неудаче платежа заказ возвращается в статус «pending» для повторной обработки, что предотвращает остатки в состоянии «processing».
  • Важно различать типы ошибок: «declined» (отказ от платежа) и «unknown» (отсутствие ответа), чтобы избежать неправильного возврата статуса.
  • Для предотвращения повторных запросов используется идемпотентный ключ, основанный на идентификаторе заявки, а не на запросе клиента.

Когда пригодится: при реализации систем, где возможны одновременные запросы от одного клиента, например, в системах оплаты, заказов или подписок, где требуется гарантировать уникальность обработки без блокировок.

DesignGurus

Generative AI System Design: The Complete Architecture Guide for 2026

Открыть оригинал ↗ Перевод заголовка: Архитектура генеративных ИИ-систем: полное руководство по проектированию для 2026 года

Генеративные ИИ-системы принципиально отличаются от традиционных: они работают на основе вероятностей, а не детерминированных результатов. Это меняет подходы к тестированию, наблюдаемости и обнаружению сбоев — в частности, системы могут генерировать ложные ответы (халлюцинации), которые выглядят правдоподобно, но не соответствуют фактической информации.

Ключевые практические тезисы:

  1. Важно разделять задачи по сложности и выбирать модель (от 1 до 700 млрд параметров) с учётом баланса между качеством, стоимостью и задержкой.
  2. Всегда использовать маршрутизацию — направлять простые запросы на небольшие модели, сложные — на большие.
  3. Обязательно внедрить слои: поиск контекста (RAG), переоценка результатов, сборка промпта, фильтрацию ответов и асинхронную оценку качества.
  4. Выбор между API-моделями (OpenAI, Anthropic) и локально запущенными (Llama, Mistral) зависит от требований к приватности, затратам и гибкости.
  5. Наблюдаемость должна оценивать не только стабильность системы, но и семантическую корректность, фактологическую достоверность и соответствие политикам.

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

Caching in System Design: 50 Concepts Every Engineer Should Know

Открыть оригинал ↗ Перевод заголовка: Кэширование в проектировании систем: 50 концепций, которые должен знать каждый инженер

Кэширование — это один из самых эффективных, но также самых опасных инструментов в системном проектировании. Оно может кардинально сократить задержки, но при неправильной реализации приводит к катастрофам: кэш-стампед, утечка данных, низкая производительность. Ключевые концепции — от базовых (hit rate, TTL) до сложных (request coalescing, probabilistic early expiration) — решают реальные проблемы в работе систем.

  • Hit rate — основной метрик, показывающий, сколько запросов удовлетворяется из кэша; 95% означает, что 90% запросов обрабатываются мгновенно.
  • TTL — время жизни кэшированного элемента; короткий TTL снижает стальность, но повышает свежесть данных.
  • Eviction policies (LRU, LFU) — выбор стратегии удаления элементов зависит от характера доступа: LRU подходит для временных данных, LFU — для часто используемых.
  • Cache stampede и request coalescing — решения для предотвращения перегрузки БД при истечении срока действия кэша.
  • Probabilistic early expiration — альтернатива блокировкам, распределяет обновления по времени, избегая синхронного истечения.

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

InfoQ Architecture

Article: Implementing Durable Workflows on Postgres Without an External Orchestrator

Открыть оригинал ↗ Перевод заголовка: Реализация устойчивых потоков выполнения в Postgres без внешнего оркестратора

В статье предлагается реализовать устойчивые потоки выполнения в Postgres, не используя внешние оркестраторы, как Temporal или AWS Step Functions. Система строится на прямом взаимодействии приложений с Postgres, где каждый шаг потока сохраняется в виде строки в таблице, а контроль за выполнением обеспечивается через стандартные механизмы базы данных.

Практические тезисы:
— Использование SELECT ... FOR UPDATE SKIP LOCKED позволяет создать безопасную очередь, где каждый элемент обрабатывается ровно один раз, без необходимости в брокерах или Redis-локах.
— Ограничение дублирования шагов достигается за счёт первичного ключа в таблице operation_outputs, что делает проверку на дублирование частью базы данных.
— При сбое работой вводится механизм «lease-and-sweeper»: активные задачи периодически обновляют сроки, а периодический скан перезапускает устаревшие.
— Ожидания и подтверждения от пользователей (например, в Slack) хранятся как строки в таблице workflow_waits, обеспечивая устойчивость даже при длительных задержках.
— Все метрики и отслеживание выполнения доступны через простые SQL-запросы, что упрощает мониторинг и анализ.

Когда пригодится:
Когда система уже использует Postgres как основную базу данных, и требуется устойчивое выполнение потоков без введения новых систем, особенно в I/O-нагруженных сценариях, где важны простота, прозрачность и интеграция с существующим стеком.

Javarevisited Newsletter

10 System Design Concepts Engineers Often Ignore but Interviewers Love

Открыть оригинал ↗ Перевод заголовка: 10 концепций системного проектирования, которые инженеры часто игнорируют, но наставники ценят

Многие кандидаты на системное проектирование изучают лишь популярные темы — такие как балансировщики нагрузки, Redis, Kafka и микросервисы. Однако именно менее известные концепции, которые часто упускаются, определяют качество и реалистичность системы в условиях реального использования. Эти идеи могут кардинально повлиять на то, насколько дизайн готов к работе в производстве.

Практические тезисы:

  • Backpressure — механизм, при котором система снижает скорость обработки, когда нагрузка превышает возможности, что предотвращает перегрузку.
  • Circuit breakers — позволяют быстро отключать неисправные сервисы, предотвращая распространение сбоев.
  • Rate limiting — ограничивает количество запросов от одного источника, предотвращая DoS-атаки.
  • Dead letter queues (DLQ) — хранят сообщения, которые не могут быть обработаны, обеспечивая возможность их повторной обработки.
  • Idempotency — гарантирует, что повторный вызов операции не изменяет результат, что критично для надёжности.

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

Coding / Algorithms

DEV Data Structures

Sliding Window: The One Ring to Rule Them All

Открыть оригинал ↗ Перевод заголовка: Слайдинг-окно: единственный кольцо, чтобы управлять всеми

Слайдинг-окно — это универсальный подход, который позволяет решать задачи о подмассивах за линейное время O(n), избегая повторного перебора. Основная идея — поддерживать активный интервал с двумя указателями (left и right), расширяя его вправо и сужая только слева, когда сумма подмассива достигает заданного порога.

  • Всегда движется только вправо (right), и только вперёд (left), что гарантирует линейную сложность.
  • Работает только при неотрицательных числах из-за монотонности суммы: добавление элемента увеличивает сумму, удаление — уменьшает.
  • Каждый элемент входит в окно один раз (при увеличении right) и выходит один раз (при увеличении left), что исключает повторные вычисления.
  • Применимо к задачам: минимальный подмассив с суммой ≥ target, максимальная сумма подмассива фиксированного размера, подстроки с не более чем k уникальными символами.

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

The Right Container for the Job: Python Data Structures

Открыть оригинал ↗ Перевод заголовка: Правый контейнер для задачи: структуры данных на Python

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

Практические тезисы:

  • Используйте список (list), если порядок элементов важен и нужно динамически добавлять, удалять или изменять данные.
  • Применяйте кортеж (tuple) для неизменяемых данных, например, координат или пар ключ-значение, чтобы гарантировать целостность данных.
  • Выбирайте словарь (dictionary) при необходимости быстрого поиска по значимому ключу (например, по имени пользователя).
  • Используйте множество (set) для хранения уникальных элементов и операций над коллекциями (объединение, пересечение и т.д.).

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

DEV LeetCode

The LeetCode Problem Anatomy

Открыть оригинал ↗ Перевод заголовка: Анатомия задачи на LeetCode

Анатомия задачи на платформах вроде LeetCode состоит из двух явных элементов — описания и ограничений — и трёх скрытых компонентов: основной паттерн, модификатор и крайние случаи. Правильное решение не зависит от заучивания кода, а строится на структурированной разборке: сначала определяется основной паттерн (например, «слайдинг-окно»), затем анализируется модификатор (оптимизационный или структурный), и проверяются крайние случаи.

  • Основной паттерн определяется из описания задачи (например, «найти подмассив длины k с максимальным средним значением» → слайдинг-окно).
  • Модификатор может требовать оптимизацию (например, использование хэш-таблицы вместо двойного прохода) или изменить сам паттерн (например, переход от фиксированного к динамическому окну).
  • Крайние случаи проверяются по границам размера, значений и предпосылок (например, k больше длины массива).

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

LeetCode 4000 - 4010 problems: patterns and approaches explained

Открыть оригинал ↗ Перевод заголовка: LeetCode 4000–4010: паттерны и подходы к решению

В статье анализируются задачи LeetCode с номерами от 4000 до 4010 (исключая 4004 и 4005), с указанием сложности и ключевых паттернов решений. Основные подходы включают грейди, двойные указатели, комбинаторику, динамическое программирование и теорию чисел.

  • Задача 4000 (Easy) использует грейди-стратегию для построения наибольшего числа с заданной суммой цифр.
  • Задача 4001 (Medium) решается с помощью двух указателей при слиянии отсортированных временных рядов.
  • Задача 4002 (Medium) применяет комбинаторику: вычитание количества последовательностей с нечётными числами для получения чётного произведения.
  • Задача 4003 (Hard) требует моделирования состояния с учётом чётности шага — используется Dijkstra на расширенной сетке.
  • Задача 4007 (Hard) решается с помощью подсчёта частот и объединения пар с суммой высот.

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