Меня зовут Вероника. Я технический проджект-менеджер в финтехе и мама троих детей: студентки, школьницы и детсадовца. Когда люди узнают оба этих факта, обычно задают два вопроса: “Как ты всё успеваешь?” и “Ты вообще спишь?”

На оба вопроса у меня один ответ — все дело в процессах, детка.

Привет, друзья! Сегодня хочу поговорить об одной из самых обсуждаемых тем последних лет — использовании AI в пентесте. За последние два года вокруг LLM сформировалось два противоположных лагеря. Первые уверены, что искусственный интеллект скоро заменит специалистов по информационной безопасности. Вторые считают, что ChatGPT способен только красиво писать тексты и не имеет практической ценности для offensive security. На мой взгляд, правда находится где-то посередине.

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

Привет! На связи команда QA Automation СВОЙ Тех. Сегодня мы хотим поднять тему, которая за последний год превратилась из хайпового «вайб-кодинга» в суровую инженерную реальность. Мы поговорим об агентной разработке (AI Agents) в автоматизации тестирования.

Этот текст завершает первую и вторую части трилогии о внедрении LLM в клиентские сервисы. Если раньше мы обсуждали ИИ-агентов и базовую архитектуру, то третья статья получилась самая «бизнесовая» в цикле.

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

AI-инструменты уже давно перестали быть просто «умными чатами». Сегодня Claude Code, Codex и другие агенты постепенно превращаются в полноценную инженерную инфраструĸтуру: с памятью, workflow, sub-agentʼами, orchestration и reusable праĸтиĸами.

В этой статье команда разработки СВОЙ Тех собрала праĸтиĸи, ĸоторые реально помогают использовать Claude Code эффеĸтивно. Дисклеймер: будет много списков — не обессудьте и, надеемся, вам так же, как и автору, легче усваивать информацию.

Привет, Хабр! На связи Кирилл Морданов, PR-менеджер Своего Банка.

Наша DevRel-команда регулярно вытаскивает на свет интересные кейсы и инсайды от технических специалистов СВОЙ Тех, чтобы вытащить наружу самые сочные инсайды. В этот раз с чашкой кофе я дошел до Алексея Ахмеева, начальника управления информационной безопасности банка.

Тема ИБ сейчас максимально горячая: атаки эволюционируют, регуляторы закручивают гайки, а дедлайны по импортозамещению КИИ уже дышат в спину. Я позадавал Алексею вопросы о том, как устроен современный Supply Chain в финтехе, где брать дефицитных специалистов и почему классический фишинг теперь пишут нейросети.

Под катом — выжимка нашего разговора без лишней канцелярщины и «воды».

В прошлом материале мы подробно разобрали кейс внедрения ИИ-ассистента. Сегодня пойдем глубже и препарируем саму архитектуру системы, которая позволяет боту оставаться полезным и безопасным в жестких рамках финтеха. 

Гибридная архитектура голосового бота в финтехе — это не «NLU + LLM», а набор слоёв, где каждый отвечает за свою часть риска и пользы: ASR (Automatic Speech Recognition – автоматическое распознавание речи), NLU, routing, API, knowledge, compliance, voice и LLM-оркестрация. В такой системе самое слабое звено почти всегда важнее самой сильной модели. Если knowledge устарела, API не даёт факты, а routing не умеет передавать на человека, никакая LLM не спасёт.  

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

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

Когда аналитика превращается в расшифровку задач 

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

Формально задача есть. По факту нет ни границ, ни сценария, ни критериев успеха, ни понимания того, что именно требуется реализовать.

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

В финтехе почти никогда не происходит по красивому сценарию, который обычно рисуют в презентациях: подключили LLM — и внезапно получили умного, почти «человеческого» голосового агента. Эта картинка слишком удобная, чтобы быть правдой. В реальности всё развивается намного медленнее и, если честно, местами довольно приземлённо.

Есть популярный миф. Мол, сначала бот живёт на жёстких сценариях. Потом к нему подключают LLM — и он сам превращается в почти живого собеседника. Звучит красиво. В реальности так не работает. Если посмотреть на реальные проекты в финтехе, всё происходит гораздо проще и… скучнее.

Этот материал — результат работы технической команды СВОЙ Тех. Как Project Manager, я прошел с коллегами путь от простых блок-схем до гибридных систем и хочу поделиться реальным опытом того, что остается «за кадром» красивых презентаций об искусственном интеллекте.

Привет, Хабр! Меня зовут Надя Скребец, я DevRel СВОЙ Тех.

Обычно здесь рассказывают про архитектурные победы, эпичные факапы или магию Kubernetes. Это круто, но за каждой строчкой кода и каждым релизом стоит человек. Сегодня я хочу показать вам CTO «Свой Банк» — Максима Гречихо.

Для многих позиция технического директора — это вершина карьеры, «финальный босс» в мире ИТ. Но какой вид открывается с этой вершины? Чтобы это выяснить, я буквально зажала Максима в углу между кофемашиной и переговоркой. Бежать ему было некуда, так что я воспользовалась случаем и заставила его поговорить со мной не о графиках и дедлайнах, а о том, почему современный СТО — это больше про смыслы, чем про синтаксис.

Кстати, маленькая гордость команды: Максим сейчас номинирован на ТОП-100 ИТ-лидеров. И знаете, что нас по-настоящему удивляет? Не сам факт номинации, а то, с какой скоростью он набирает голоса. Кажется, его подход «быть человеком в ИТ» находит мощный отклик.

— Максим, у тебя за плечами 17 лет в ИТ, опыт в гигантах вроде ВТБ и запуск банков с нуля. Ты прошел путь от разработки до управления огромными вертикалями. Расскажи, в какой профессиональной точке ты находишься сейчас и какие планы в новом проекте?

— В данный момент я занимаю позицию технического директора (CTO) в одном из ключевых проектов финтех-группы СВОЙ. Я узнал о группе от коллег и был поражен амбициозными целями банка, культурой компании и ролью ИТ в бизнесе. Желание стать частью такой команды возникло практически мгновенно.

Сейчас в мои обязанности входят управление всей ИТ-командой Банка, взаимодействие и активное участие в развитии бизнеса через наши кроссфункциональные команды, работа с ИТ-бюджетом, ФОТом и КПЭ. Планы у нас достаточно большие: Банк одновременно занят серьезной трансформацией ИТ-ландшафта, внедряя новую АБС и активно реализуя новые бизнес-сервисы. Это накладывает особую ответственность и необходимость очень профессионального подхода к управлению ресурсами, командами и проектами. Так что главный пункт — осуществить задуманное и реализовать все в сроки с нужным качеством. В дальнейшем, конечно, это развитие команды и ИТ-процессов.

Использование ИИ в разработке давно вышло за рамки генерации простых функций. Для крупного финтеха это вопрос системной интеграции и безопасности. В ИТ-кластере «СВОЙ Тех» мы постоянно ищем способы оптимизации Time-to-Market. В этом материале мы делимся опытом того, как заставить нейросети работать с легаси-кодом, зачем им доступ к Figma через MCP-протокол и почему будущее за Spec Driven Development.

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

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

Сегодня использование AI-ассистентов вроде Cursor или Windsurf стало стандартом, но многие разработчики по-прежнему используют их как «улучшенный Google». В реальности современные LLM — это изолированные вычислительные ядра, эффективность которых напрямую зависит от того, как вы выстроите архитектуру контекста.

Основываясь на коллективном опыте внедрения AI-инструментов в финтех-проекты, команда разработчиков финтех-группы «Свой» собрала системный гайд по превращению нейросети в предсказуемого и автономного агента.

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

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

— Я внедрил Agile, использую генеративный ИИ и веду квартальные OKR-сессии.

Коза округлила глаза:

— Вот оно! Нужно срочно начать проводить стендапы!

Осел закивал:

— А я сразу закажу какой-нибудь модный AI!

Эта тема претендует на такую же вечную, как софт/хард-скиллы, первично бытие или сознание, что было раньше — курица или яйцо :) Даже среди коллег я встречала мнение, что manual QA не очень-то полезны: «Чё там делать, сиди себе, monkey-testing лепи». А с темпами развития ИИ QA должны были ещё больше испугаться, вот же Copilot от GIT и Microsoft и миллион менее известных, но не менее популярных нейросетей, которые уже пишут код, они что, пачку тестов не сделают, да ещё и автотестами покроют?..

Дисклеймер:

Я работаю тестировщиком уже около восьми лет, сейчас — на проекте Свой Банк. До этого ещё семь лет работала в веб-студии, занимающейся разработкой приложений, связанных с ресторанным бизнесом и доставкой еды. Дальше — моё маленькое философское рассуждение о том, заменит ли нейросеть мою работу, исходя из того, что я вижу в it.

Как повысить лояльность и уровень мотивации в команде? Практически каждый уважающий себя Project Manager сталкивался с данным вопросом или, как минимум, рассуждал на эту тему в контексте “а что, если бы..”. Причины, которые могут приводить к таким мыслям или нужде могут быть разные: 

В последние годы наблюдаются значительные изменения в банковской сфере, обусловленные развитием цифровых технологий. Одним из наиболее заметных трендов является запуск цифровых банков, которые предлагают клиентам высококачественные финансовые услуги с использованием современных информационных систем. В этом контексте автоматизированные банковские системы (АБС) играют ключевую роль в обеспечении эффективной работы цифровых банков. В статье будут рассмотрены особенности запуска цифрового Своего Банка на базе автоматизированной банковской системы RS-Bank, преимущества и недостатки, а также преодоленные вызовы и риски.

 Понятие цифрового банка и его преимущества

Давайте посмотрим на выбор между Agile и классическим управлением проектами на примере постройки дома с участием козы, осла и муравья (добавим немного сарказма).

Пример: Постройка дома

👀 Классика:

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

Строительство началось по расписанию. Осел, конечно, сразу захотел бассейн, но муравей сказал: «Подожди, осел, сначала закончим крышу, потом — бассейн». Коза решила, что ей нужен балкон, чтобы наблюдать за закатом, но муравей снова был непреклонен: «Балкон только в следующем проекте. Сейчас у нас дом по плану!»

В итоге, дом был достроен. Осел получил спальню, но без бассейна. Коза — стойло, но без балкона. Муравей был доволен своим уголком, но коза и осел ворчали. Зато всё по плану! К сожалению, унитаз оказался в стойле осла.

👀 Agile:

Теперь представим, что коза, осел и муравей строят дом по Agile. Начали они с одной комнаты. Коза въехала в эту комнату и сразу заявила: «Мне тут тесно, хочу балкон!» Муравей записал это в задачи следующего спринта. Осел посмотрел на всё это и сказал: «Мне нужен бассейн, а то я вообще не перееду!»

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

В компании “Свой Банк” мы активно развиваем лучшие практики и стандарты в Backend-разработке. Но, прежде чем выработать хотя бы одну практику, необходимо изучить материалы, разобраться в теме и выработать подходящий вариант. Поэтому в данной статье затронем основные понятия и концепции работы null-безопасности в объектно-ориентированном языке программирования Java.

Что такое Null-безопасность и Nullability

Nullability — это концепция, которая описывает, может ли переменная или выражение содержать значение `null`. Несмотря на свою кажущуюся простоту, работа с `null` часто становится причиной сложных ошибок, таких как `NullPointerException` (NPE). Из-за этого возникла концепция null-безопасности, целью которой является защита кода от ошибок, связанных с `null`.

Null-безопасность означает, что в коде либо отсутствуют `null`-значения, либо они обрабатываются явно и безопасно. В Java существуют разные подходы к обеспечению `null`-безопасности, которые позволяют управлять возможностью появления `null` в коде и минимизировать риски, связанные с их использованием.

Итого Nullability - это способность объекта быть `null`.

Null-безопасность - это свойство языка программирования безопасно работать с `null`.

Так заведено, что сложные проекты требуют серьезных инструментов. К примеру, финтех-продукты холдинга IDF Eurasia, в том числе и Своего Банка, где я работаю, разрабатываются на далеко не самых простых языках Java и Kotlin. И, казалось бы, использование сложных форм — это само собой разумеющееся. Но из головы никак не выходят low-code инструменты, минимизирующие объем работ для запуска функционала, о которых без устали говорит IT-сообщество. Вот и на Хабре уже, казалось бы, все писано-переписано. Но давайте все же еще поразмышляем))